The scenario is that a friend brings round a USB stick containing a selection of audio tracks that s/he would like to hear on your Roon system. I did the following, which gave unexpected results:
I get a USB stick with a variety of files culled from different albums. For example:
I plug the USB stick into a PC or Mac that is running a Roon Remote (in my case, Roon Core is running on a ROCK NUC), and I drag and drop the DATAUSB icon from the Windows File Explorer into Roon. The following screen pops up:
So far so good. I say I want to copy the files (because it is not possible to add a USB stick as a shared folder in Windows). I expect to see the files grouped into albums (whether identified or not) that will appear in the ārecently addedā display on the Overview screen. Instead, nothing apparently happens; the display remains as it was:
So I go to the Tracks browser, display the Path, and filter on the word āImportedā. I discover the files have been imported, but with a date added of ā1 January 1ā:
Thanks for the feedback @Geoff_Coupe and @AMP! I am going to have the team bang on this a bit to see what we can come up with. I will be sure to update with findings once testing has completed.
@Geoff_Coupe and @AMP ---- Thank you both for your patience and understanding here. Weāve been quite busy getting this release out the door so it is very appreciated!
Myself, along with @dylan and @noris have been working to try and re-create the behavior that you have both reported in this thread in a variety of testing environments to see what we could come up with. All of our testing was conducted with the previous build (i.e 339) and with the most recent build (i.e 354).
In all test runs we were unable to get Roon to produce the same results mentioned in your posts. I did see a remote crash happen once during the drag/drop/import process but this was resolved by a simple reboot of one of my test cores and the behavior did not repeat despite how much stress I tried to put on the system.
Are you both still seeing this with B354 and if you are, are there any other details you can provide me with to make this happen on our end? If there is a bug here we would definitely like to get it in front of the DEV team but as you both know we must make it reproducible first.
@eric - Iām afraid that this is still happening here. Iām using Roon build 354 running on Windows 10 on my desktop PC, and Roon Server build 354 running on ROCK on an Intel i5 NUC (NUC7I5BNH), which has been transposed into an Akasa fanless housing. Dragged and dropped a folder using Windows File Explorer onto the Roon Overview screen.
All cores are at the most current revisions and either Nucleus+, ROCK, or Ubuntu. I canāt get the ROCK or Nucleus cores to reproduce the issue, but Iām also having a lot of trouble finding music files that arenāt already in the library on those cores. All are using local storage as the target for the drag-and-drop.
On the Ubuntu core (running 354) Iām getting pretty consistent results with the albums showing a 1/1/1 import date. The files are being written to a local disk formatted ext4. After several import / delete / import cycles using the same tracks it got the date right on 1 out of 4 tries. Iāve also tried different permutations of dragging individual files vs the entire album folder vs the album folder contained within an artist folder and the results are the same. Also doesnāt seem to matter if Roon can or canāt identify the album.
I could send you an album which is failing, but itās only failing on this one core. Youāre welcome to grab logs if you like (core name roonvm1). Did these tests immediately after doing the 354 update so all of the action should be in the most recent log file.
@Geoff_Coupe and @AMP ----- Thank you both for the update and additional insight. Very appreciated!
I am going to schedule some more testing to see if can get this to happen in house and if we cannot we will look into enabling diagnostics and check logs. I will be sure to touch base again when the next round of testing has completed. Again, many thanks to you both!
I have had our QA team trying to reproduce this behavior and they have been getting some mixed results. In light of this the team has asked me to gather some core and remote logs from @Geoff_Coupe so they can have a closer look into this behavior being experienced.
Geoff, with this in mind may very kindly ask you to please perform the following:
Please reproduce the issue and note the time when it occurs.
So I go to the Tracks browser, display the Path, and filter on the word āImportedā. I discover the files have been imported, but with a date added of ā1 January 1ā
Sure enough, if I go to the Albums browser, sort by Date added, the contents of the USB stick are there as my oldest albums
After the issue has been reproduced please use the support ID found just below in conjunction with the instructions found here to send us over a set of your logs
support ID: e99e7dd6-a5f0-4ca6-834e-fcf8ddc41572
Note: The support ID should be entered in on the Win10 remote where the issue was reproduced. This procedure will provide us with logs not only from the Win10 remote but also from your core machine as well
Iāve reproduced the issue (at 17:23 CET) and tried to send the logs - but am getting a āWe couldnāt connect to our serverā error message. Iāve saved the support package - what do I do with it? Thanks.
@Geoff_Coupe and @AMP ā Again, thank you both for your continued patience and understanding while our team has been trying to run down this behavior in house.
As you both are aware, our tech team have been having difficulties reproducing this behavior in house and as such we met today to discuss the tickets I opened for both of your reports. Our techs have asked if you both would kindly provide the following:
Andrew, you mentioned here that the files are ābeing written to a local disk formatted ext4ā. My understanding is that this type of formatting will not work on MAC and would like to confirm what was used when you tested on OSX? Thanks!
Geoff, the team would like a new set of logs from your system and as such may I kindly ask you to perform the same procedure listed above. If you run into the same error message please proceed with the work flow discussed in our PM chain.
That is correct, but I think something got lost in communication.
The core is running Linux and mounts most of its content via NAS. So as to remove the NAS from the equation (and keep from making a bunch of changes to the NAS library) I setup a new storage location on the root partition of the coreās boot drive. Itās formatted ext4.
All of my experience with this issue has been using a MacOS 10.13.6 remote connected to a linux core.
As an aside, I was at a customerās home and dropped a file onto his core (one of our firmware updates, which is a WAV file). That file came up with the same 1-JAN-1 import date.
His core is Ubuntu 16.04 on a NUC. Music storage is on a synology NAS. Remote running on MacOS. In my case, at least, the common element seems to be linux / ext4.
Weāve recently released Roon 1.7 (Build 521) which includes changes that should improve this behavior. Please give it this a try and let us know how it goes!
Hi @dylan - it is now working properly. One thing to watch out for is how the files are organised.
If they are a bunch of individual files, each with different date and timestamps for the file creation/modified dates, then both albums and files in the Roon Library will be marked with the date/time of Import.
If, however, the files are in a folder, and the folder is dragged and dropped into Roon, then Roon sets the date added of the album to be whatever the folder has as the folder creation date.
Hereās an example. I dragged and dropped a bunch of individual files created several years ago, and a folder containing a couple of Yo-Yo Ma tracks. The latter had been created on the 7th January 2020. In the Album browser, the individual files have been clumped into four albums, with a āDate Addedā set to today. The Yo-Yo- Ma album has been created, but the āDate Addedā has been set to the 7th January 2020 - the timestamp of the folder.
