SirAtilla

Well said. When I did my experiment it was to prove the file was persisted to the device. That is easy to prove. I hypothesized that the file was likely cached to the playback SSD. Further information indicates Aurender is leaving it in RAM for persistence. There are a number of choices and they are only ones to really clarify that. So seems like we have conclusive information at the moment which is cool. I am personally interested in information not affirmation.

I respectfully disagree like I said based on "experiential" data. I re-did my experiment again before this post and anybody else can reproduce it on their own Aurender. I went to latest releases on Qobuz via Conductor and chose a song 5:05 long and clicked play To add additional data to my experiment I added a 2nd song from Qobuz to the queue I let the song play for 10 seconds and then paused it via Conductor - I chose 10 seconds for adequate download time - this was a track in 24 bit/96 kHz resolution I then disabled the switched port to my Aurender and within 2 seconds Conductor was disconnected from the Aurender Using the physical buttons on the Aurender I resumed playback The song played with no network connection to completion - another 4:55 The 2nd song in queue did not play which indicates there is no pre-fetch of queue content My conclusion, as it was before when I did this experiment, is that at least for Qobuz content, the track is completely downloaded to the playback SSD. If there was some sorta of largish RAM buffer memory based playback like what PS Audio did with the DirectStream memory player, I am sure they would have marketed this.

This definitely aligns more to my experience with Qobuz content that it appears it was using the local playback SSD. Thanks for the follow-up post.

Those are storage SSDs not the caching/playback SSD. All Aurenders have an internal SSD for playback regardless of if you use the user-installable trays. For example my W20SE has 2 8TB storage SSDs (Music1 & Music2) and a 1TB SSD from the factory for caching/playback not user accessible. The size varies depending on model but that has been a standard since the original S10 a decade ago+.

The context of this was lost in a few posts - we are discussing strictly whether streaming from Qobuz/TIDAL caches onto the playback SSD. According to Eric it does not. Your statement is absolutely correct about files stored locally on the Aurender or on a connected ACS.

Sounds like latest version of Conductor 4.11 has the support to turn this on/off just needed the device firmware?

Eric would definitely know for sure so that is source of truth. Experiential the buffer is pretty good size maybe 15-20 seconds to protect against network blips or inconsistencies. I may do an experiment just to understand how much gets buffered and suspect somewhat dependent on resolution of source file.

As far as SSD based cache/playback I believe that is limited to locally stored content and to some extent TIDAL/Qobuz content. I have done experiments pulling the ethernet cable after starting a song streaming from Qobuz and it appears to continue playing the song which must mean its caching the file. This may also be dependent on the streaming service offering the capability to download songs. I have never experimented with Spotify so can't offer much for that implementation. I am pretty certain that digital content coming into a A series Aurender with an onboard DAC via a optical or analog input does not utilize SSD based caching just normal buffering any DAC would do.

I have done this only once and it was several years ago where I took a SSD from one Aurender and placed it another. As I recall there was a little lag at initial boot up and recognition but eventually it did stabilize and worked from that point forward. I would definitely get Aurender supports take on this change. Best

Yeah totally get it and exFAT is of course another file system with yet different capabilities.

Hi, If you use the built in backup in Conductor it should create a backup of your ratings, playlists etc. in a backup folder of the ACS10. The playlists are exported in a subfolder called playlists and are a simple flat file with .m3u extension. You should able to download that file and open each playlist and edit the file to reflect the locations on the W20 (ie Music1/Music2 and path). If you simply split your 5.6TB library from Music1 to a dual drive Music1/Music2 should be pretty easy to make the changes. Once you have updated those files do a backup on the W20 and replace the playlists in that backup with your updated files then ultimately restore on the W20. I attached an example small playlist from my W20SE. It should be as simple as adjusting Music1 to Music2 for the files that were split onto the 2nd drive in the W20. I wrote a blog article about the details of how backups are structured in 2019 and some of the manipulation that is possible - its at this link: https://www.sound-lab.com/blog/aurender-playlists Hope this helps.ANA[DIA]LOG Reference.m3u

Good suggestion but I think this will only merge files in format ._*. A useful command for sure. Before I sync my library to my Aurender (I never work from Aurender I work from a local copy to computer) I have a few commands in a shell script that my sync program (Chronosync) executes before it syncs the library. For example I use commands to remove things like .DS_Files, Extended Attributes (xattr command), find and remove any empty directories, etc. then the sync program is also configured to ignore these things if one happens to get by. Using a file sync program that is OS aware can be incredibly useful to understand file system differences and give you fine grain control over the sync process.

Hello, Conductor is just the app on the mobile device doesn't have anything to do with these particular issues. I have never seen any permissions issues. While the error messages may say that I have never found it to be the case as you don't have control over permissions in the underlying Linux based filesystem on the Aurender. Finder on macOS has quite a few quirks that have gotten better over the years but its underlying support of old HFS/HFS+ and now APFS file systems that have different fundamental capabilities leads to some debt. Items like resource forks, extended attributes, .DS_Store, and various other things can lead to unnecessary items being written to the Aurender file system.

I would use the command line as outlined in the follow-up post. It's likely a hidden file that is causing issues with macOS Finder. I have seen this a few times. Whether macOS or Windows I would recommend using a file transfer utility versus graphically interacting with mounted file system mainly because both OSes have a lot of "legacy" stuff and can write out various hidden files to keep track of things like window positions that have zero to do with music playback. The Aurender will ignore them but just no reason to have them on its filesystem.

I am not interested in Roon myself however I see this as good thing. I think Roon is a very nice product it just doesn't offer me my engineering ideal of a music transport. Some prefer it and that fine with me its chocolate or vanilla and that is a good thing for the industry. Conductor development is ultimately driven by unit sales and the ability to support the costs of the software team. If more units are sold due to Aurenders being a Roon endpoint it ultimately helps Aurender to cover software costs or even expand their development. When I discussed this implementation with the owner and engineering lead at AXPONA last year Roon ignores one of the primary advantages of an Aurender and that is local storage + local cached playback. A Roon endpoint is designed to take a stream from a Roon Core and play it back. It means an Aurender ignores its local cache drive for playback. This is because Roon has no support for this concept. Aurender could make the local drive available to Roon as a source but that means the data would go from local storage in Aurender to the Roon Core back to the Aurender and still ignore the cache drive. That makes little sense. These are limitations of the Roon implementation framework as I understood it. Caveat: this was AXPONA 2023 information I plan to discuss if any changes occurred over past year but I suspect not unless Roon/Aurender agreed to add some capabilities.