Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[RD James]

All forms of Memory Playback, 32 or 64 bit, still doesn't seem to be working at all for me in this build. Just seems to be playing direct from the disk.

[Awesome Donkey]

Yeah, the full album memory option has been hit and miss for me too (I can usually get it working with playing DSF files first... for whatever reason... then playing FLAC files again). Still figuring out the pattern to help find what the issue is. But it looks like the other options still work for me... I'll check them to see if there's a regression there or something.

[Matt]

All forms of Memory Playback, 32 or 64 bit, still doesn't seem to be working at all for me in this build. Just seems to be playing direct from the disk.

How are you verifying that?  Memory playback is a silent operation, so it behaves pretty much the same.  You can watch the memory usage and that should grow in memory mode.

[Awesome Donkey]

Huh, it appears the load full file (not decoded) into memory option seems to be failing to load 24/192 FLAC files too. Just tried a 230MB 24/192 FLAC file and it didn't load (or increase MC's memory usage).

On the other hand, it appears the load the decoded file option seems to work just fine. Strange.

I'm using multiple tools to monitor resource usage; Task Manager, Process Explorer and Process Hacker. Not observing just private working set either, but shared WS, WS delta and the peak.

Wonder if it'll show up via logging?

[mojave]

64-bit memory playback with "load full album" is working for me with APE and up to 96 kHz FLAC files.

I have a separate drive with only the music on it. With an album of 88.2 kHz FLAC files it took 62 seconds before disc activity ceased. Memory usage for JRiver is at 1.67 GB. I then tried an album of 96 kHz FLAC files and it also took 62 seconds before disc activity ceases. Memory usage is at 1.2 GB. It shows it is reading all the album files during the 62 seconds.

192 kHz FLAC files are not loaded into memory.

I have album folders and JRiver processes excluded in Windows Defender. I also disabled real-time protection for the testing.

[RD James]

How are you verifying that?  Memory playback is a silent operation, so it behaves pretty much the same.  You can watch the memory usage and that should grow in memory mode.

You can use Process Explorer to monitor what any application is doing in terms of memory usage and I/O, how many threads tasks are able to use etc. https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx

In v57+ there was no increase in memory usage and lots of I/O activity during playback - especially when seeking.
In v45 there is an increase in memory and no I/O activity at all during playback or seeking when the "load full file (not decoded)" memory playback is activated. The only I/O activity is the last few seconds before it changes to the next track.

 
However I've found two failure states for the "album" memory playback:
If I use a "play" command - whether that's clicking the play button, hitting play on my remote, clicking a car radio button, or right-clicking files and selecting "play", memory playback is not activated.

If I double-click a track in the Playing Now list, memory playback works as expected.
But if there are more than 15 tracks, it doesn't activate at all.
If there are 15 tracks and you add more, it also breaks memory playback.
 
"Load decoded file into memory" seems to have similar issues, where there's lots of I/O activity when doing things like seeking, even in v45.
I don't know if it's always been like that or if it broke at some other point in time, as I don't use that option.
 
 
 
On the subject of Process Explorer, I also noticed that when "Verify Image Signatures" is enabled, it reports that "No signature was present in the subject" for Media Center.

[Awesome Donkey]

Interesting, you might be onto something here. It does indeed work if I play an album (in this case 16/44.1 FLAC, 11 tracks) by navigating in the tree to Playing Now > Player. If I directly try to via my custom panes view it doesn't seem to work at all.

Meaning if I try to play an album from my custom panes view full album memory playback won't work. However if I stop the album's playback and I navigate in the tree to Playing Now > Player and restart the playback of the album there, it loads into memory and works.

EDIT: 24/192 FLAC (same album as above for the test, 11 tracks) works this way too.

[RD James]

Oh something else: if you're playing high-res tracks, it seems like it doesn't start playing until everything is loaded into memory.
So if you're playing 3GB of tracks, you have to wait until all 3GB is loaded into memory instead of playback starting after the first track is loaded, which might only be 200MB.
With a slower disk or network connection that can be quite a wait, and MC appears to freeze during this.

[Awesome Donkey]

This is true too, saw this when I was testing the loading of DSF tracks too - MC's UI will momentarily go "not responding" until it's loaded into memory.

It's worth noting that in my testing thus far it seems that DSF does load correctly into memory regardless for the first load. If you try to load another DSD album it'll load into memory then drop down (to seemingly usage of just the full file being loaded, instead of the full album). If I repeat the workaround above by going to Playing Now > Player (DSD) and restarting the album there, it works.

But definitely FLAC files of various bit-depths/sample rates that seems to have consistent issues here.

[dtc]

I have found that loading the album into memory has worked well, using Windows 7 and 8.1. I do not see the anomalies that others see. The album loads and the memory goes up accordingly. It stays at that level until I stop playing or change to another album. I have tried this with 2xDSD, 24/192 and 16/44 FLAC files. If I stop an album playing, memory drops back to idling size. If I click on track 1 of a new album while another album is playing, memory grows from its current value and then falls back to the full album size when the new album starts. I always start albums for Standard View. I do not using Playing Now or Panes.  I do find that if I select another track in the playing album then memory changes sometimes but not always. It seems to be related to how far down the track list I go, but I have not done this systematically.

For those that are seeing volume changes when playing, it might be the sequence of selection or the place where the selection is being made - Playing Now or Panes versus Standard View.  As an experiment, you might want to try just using standard view only and see what you see.

I am really happy that play album from memory works on both 32 and 64 bit versions. My main playback system is still 32 bits and this will be a nice option on it.

[dtc]

Load album to memory - When the album is larger than the available memory, the system hangs. This is with the 32 bit version on Windows 7.

[dtc]

After some more experimentation, it appears than loading an album of 15 or fewer tracks works as expected. However, if there are more than 15 tracks, it does not try to load tracks into memory and it reverts back to not playing from memory at all. I understand the difficulty of reloading 15 tracks in the middle of playing a longer album - it can causes pauses and glitches. But, it seems like if it cannot load 15 tracks, the default should be to load individual tracks into memory not revert to accessing disk throughout a track. 

In addition, it would be nice if the limit were not a hard limit based on number of tracks, but was based on memory availability. One of my test albums is a 20 track album but only takes up about 700 MB. It seems like an album like that should be loaded into memory, considering another album of 12 tracks loads into 3.8 GB.  If it is not possible to do the memory assessment, then maybe change the 15 track limit to something like 20 or 25 - or make it a user defined limit - assuming there is a reliable fail over method if not enough  memory is available.

These test were done on 64 bit software, with windows 7/8.1

 

[Matt]

After some more experimentation, it appears than loading an album of 15 or fewer tracks works as expected. However, if there are more than 15 tracks, it does not try to load tracks into memory and it reverts back to not playing from memory at all.

It will revert back to loading a single file at a time into memory if there are more than 15 tracks.

[dtc]

It will revert back to loading a single file at a time into memory if there are more than 15 tracks.

That is not what I see. If I look at the resource monitor there is constant disk activity in this case.

Let me modify that - sometimes it seems to default to loading the full track and sometimes it does not. I am not sure of the conditions that lead to one behavior or another. I will continue to investigate.

EDIT: It appears that when each track starts there is disk activity for up to a minute then it stops. So, it looks like it is loading slowly while playing from memory. I would expect it to load all at once before playback and then disk activity to stop before playing. Not sure what is happening.

[RD James]

I spent some more time testing and thinking about this over the weekend.

1. It seems like skipping to the previous track does not work with the "play album" option.
When I do that, it continues playing the current track for 10-20 seconds, then skips to the next track, while marking the current and previous tracks as having playback errors.
 
2. I think that looking at this as buffering "albums" into memory, or a set number of tracks, may not be optimal.
15 tracks can be anything from <100MB to several gigabytes, and 10 minutes to several hours.
11GB is the most I've been able to hit so far. That took two minutes before playback started since it waits until everything is buffered, and was 12 hours of music which seemed excessive.
 
If we take a step back and look at why someone would want this feature, the main reason to load tracks into memory is to prevent delays when seeking through tracks, ensure that gapless playback is gapless over a slow connection, and make skipping back/forward instant.
 
The absolute minimum for that would be to keep the previous track, current track, and the upcoming track in memory at all times.
That way when it changes tracks, the next one is always in memory and it can buffer the upcoming one while the current track plays.
It would ideally keep several upcoming tracks in memory and perhaps two or more previous tracks, but this would be a continuous buffer. Not 15 tracks at most and then reverting to per-track playback if you go over that limit.
 
I know that you don't like adding options to the program, so I'm trying to think what would be the best solution that would not require any configuration.
Two previous tracks, the current track, and three to five upcoming tracks should ensure that playback is completely gapless and free of delays the majority of the time, but it may not account for very short tracks in-between longer ones, or very long tracks.
If I pick the three largest tracks in my library, that's still 5GB of memory and 3 hours of music it would queue up.
 
A "simple" solution may be to fill 2GB with as many upcoming tracks as possible, but that gets kind of ridiculous with CD-quality or lossy tracks. 2GB of MP3s could be several-hundred tracks and a full day's worth of music.
I suppose you probably wouldn't have a playlist that large, but it would be buffering 3-6 hours of music with some of my smartlists.
That's not a problem, it just seems unnecessary.
 
Some kind of rule that would keep a minimum of 2 upcoming tracks and up to 20 minutes of upcoming audio buffered at all times might work best.
Even with the extreme outliers in my library the maximum memory usage would be kept to about 2GB - and would typically be much lower than that. It would typically buffer something between 3 and 7 upcoming tracks too.
That way you can always skip a track instantly - and likely several - but it's not using excessive amounts of memory, and it still has plenty of time to buffer the next tracks.
I don't know if that's feasible, but that rule seems like the most practical if you're not wanting to add more preferences.

[dtc]

...

If we take a step back and look at why someone would want this feature, the main reason to load tracks into memory is to prevent delays when seeking through tracks, ensure that gapless playback is gapless over a slow connection, and make skipping back/forward
 
...

Some kind of rule that would keep a minimum of 2 upcoming tracks and up to 20 minutes of upcoming audio buffered at all times might work best.

That way you can always skip a track instantly - and likely several - but it's not using excessive amounts of memory, and it still has plenty of time to buffer the next tracks.

These are not my primary reasons for wanting this option. I want to load the album and just let it play, without any disk access. That allows playing without the possibility of any pauses or glitches between tracks or when loading files. I want to eliminate repeated buffering. Any buffering when actual playing can cause problems as can loading more than one file during a gap, especially if you have slow access to the files over something like a usb or network connection.  Moving back and forth between tracks is not something I am looking for. I want it to load my 700 MB 16/44 album or my 4 GB DSD file completely into memory and just play it.  My system is dedicated to playing music. I want MC to use as much memory as possible to minimize disk access. I understand your usage, it just does not fit with my needs.  It would be nice to be able to accommodate both needs,  something like a slider with Quick Access on one end and Minimize DIsk Access When Playing on the other, but it would be  much more complicated to implement.

[RD James]

Another bug: when adding videos to a zone, MC is buffering them into memory (freezing the player) and then dumping it out of memory as soon as it completes - presumably since it's not an audio track.
Was the memory playback setting always global rather than per-zone?

These are not my primary reasons for wanting this option. I want to load the album and just let it play, without any disk access. That allows playing without the possibility of any pauses or glitches between tracks or when loading files. I want to eliminate repeated buffering. Any buffering when actual playing can cause problems as can loading more than one file during a gap, especially if you have slow access to the files over something like a usb or network connection.  Moving back and forth between tracks is not something I am looking for.

This is why I proposed a rule which keeps a minimum of two tracks ahead, and 20 minutes of audio.
Both of these rules are important since some tracks themselves may be longer than 20 minutes, and you still want to keep at least two buffered. Some tracks may only be 1-2 minutes long, so you would want to buffer as many as necessary to create a 20 minute buffer, rather than only one or two ahead.
 
Even that is probably excessive, but I chose that because I feel that it strikes a good balance between preventing playback issues for very slow connections, and keeps memory usage to about 2GB at most whether the tracks are full high-res gapless albums stored as a single track that are about 1GB in size, or 2xDSD tracks that are about 100MB/minute.
It also means that memory usage will be considerably lower for CD-quality or even high-res PCM tracks.
If it is taking more than 20 minutes to buffer the next track, you have bigger problems.

I want it to load my 700 MB 16/44 album or my 4 GB DSD file completely into memory and just play it.  My system is dedicated to playing music. I want MC to use as much memory as possible to minimize disk access. I understand your usage, it just does not fit with my needs.  It would be nice to be able to accommodate both needs,  something like a slider with Quick Access on one end and Minimize Disk Access When Playing on the other, but it would be  much more complicated to implement.

Well, I don't think that is typical, and if it has been increased to 20 tracks now according to Matt's recent post, that means it could be using about 13GB if I use the largest tracks in my library. Using that much memory is stupid.
 
Our goals here are the same: never let a slow connection/drive interrupt playback - which is a real problem that I experience in Media Center today, whether memory playback is enabled or not.
The solution to that should not be building a system with a ton of memory and loading several hours or days worth of audio into it.
Smarter buffer management is the solution.

If you're not even wanting to skip tracks forward/backwards without delay, and only care about sequential playback as you said, you would need less buffered in memory than I have proposed, not more.
The reason to queue up as much into memory as I've proposed is so that you can still skip a track or two without emptying the buffer and waiting for it to load.

I do hope that these suggestions are taken to heart, because I can't think of the last time I have had a Playing Now list which has fewer than 50 tracks in it.
I mainly use smartlists for playback rather than playing a single album at a time - and many albums have far more than 15-20 tracks on their own. The largest album I have in my library is a 200 track compilation, and many are 30-40 tracks - but I'm not asking to buffer the entire thing at once.
Falling back to per-track buffering if there are more than 15-20 tracks in the Playing Now list means that the feature may as well not exist for me right now though.

[dtc]

RD - What you want is a generalized memory management system for all playback, including playlists. That would be a nice feature but is, I fear, more complicated than Matt wants to take on. The design here was always to play an album from memory, not design a general purpose memory playback system. Album playback works for me but not for you.

I think a compromise might be to allow the user to set the number of tracks and the amount of memory to use. Personally I would probably set it at 20 tracks and 5 GB. That would cover pretty much all my albums except for multi disc albums and boxed sets.

The trouble with handling boxed sets and playlists is that you are always going to have to load more into memory during playback. That can cause problems if it is done when something is actually playing and it can cause too long a gap if done between tracks. That is why I think the fallback to loading single tracks makes sense. I guess another option would be to have a user defined number of tracks to load, in your case probably 2 or 3, in my case 20, before it defaults to single track loading. But that becomes more complicated.

By the way, Matt changed his post of 20 tracks back to 15. I think it was just a typo. I would like 20, but I am not sure it will happen.

[Matt]

By the way, Matt changed his post of 20 tracks back to 15. I think it was just a typo. I would like 20, but I am not sure it will happen.

Coming next build:
Changed: Upped the cap on memory playback tracks to 30 since it now makes sure it will take less than one gigabyte.

[dtc]

Coming next build:
Changed: Upped the cap on memory playback tracks to 30 since it now makes sure it will take less than one gigabyte.

Thanks Matt - higher is better, but becomes problematical if the memory is limited to 1 GB.

I do not understand the 1 GB limit. If you change it to that it pretty much eliminates this option for use with high res and DSD albums. And, at 30 tracks and only a 1 GB limit, many Redbook albums such as dual albums mayl not fit. With most 64 bit systems having 8 GB or more, only allocating 1 GB seems very low. Can you make the memory size an user settable parameter? Or maybe use 1 GB on the 32 bit version and some higher number like 5 on the 64 bit version. I hope you rethink any change to 1 GB. What is your thinking here?

[RD James]

RD - What you want is a generalized memory management system for all playback, including playlists. That would be a nice feature but is, I fear, more complicated than Matt wants to take on. The design here was always to play an album from memory, not design a general purpose memory playback system. Album playback works for me but not for you.

I think a compromise might be to allow the user to set the number of tracks and the amount of memory to use. Personally I would probably set it at 20 tracks and 5 GB. That would cover pretty much all my albums except for multi disc albums and boxed sets.

The trouble with handling boxed sets and playlists is that you are always going to have to load more into memory during playback. That can cause problems if it is done when something is actually playing and it can cause too long a gap if done between tracks. That is why I think the fallback to loading single tracks makes sense. I guess another option would be to have a user defined number of tracks to load, in your case probably 2 or 3, in my case 20, before it defaults to single track loading. But that becomes more complicated.

By the way, Matt changed his post of 20 tracks back to 15. I think it was just a typo. I would like 20, but I am not sure it will happen.

The point is to keep a buffer full all the time. When one track moves out of memory, you move another track into memory.
Filling the memory with 30 tracks, emptying it, and then filling it with another 30 only delays the inevitable if you have a disk that is slow to wake/access, or a slow network connection. After 30 tracks you'll have a gap in playback.
But the current "album playback" system doesn't seem to be that. It's 30 tracks or less, or else it falls back to playing one track at a time. So it does little to fix gapless playback on a slow disk/network.
 
That's why I suggested a rule which is 20 minutes of audio, with a two track minimum.
It almost guarantees that it will keep memory usage below 2GB total, while also ensuring that you are never going to run into gaps caused by slow disk/network access.
But it would require that the buffering system is capable of loading more tracks in, instead of having a fixed limit and falling back to per-track buffering.

[kr4]

Thanks Matt - higher is better, but becomes problematical if the memory is limited to 1 GB.

I do not understand the 1 GB limit. If you change it to that it pretty much eliminates this option for use with high res and DSD albums. And, at 30 tracks and only a 1 GB limit, many Redbook albums such as dual albums mayl not fit. With most 64 bit systems having 8 GB or more, only allocating 1 GB seems very low. Can you make the memory size an user settable parameter? Or maybe use 1 GB on the 32 bit version and some higher number like 5 on the 64 bit version. I hope you rethink any change to 1 GB. What is your thinking here?

I agree with you.  A quick scan of my library shows that there are about 120 files which are larger than 3.0GB, topping out with one at 14.5GB!  I've got lots of RAM.

[Matt]

Next build will have this:
Changed: Switched the cap for memory plabyack track loading to 2GB on 32-bit and 16GB on 64-bit.

[Awesome Donkey]

Just wondering, any ideas why the full album memory loading still isn't fully working for some of us (e.g. attempts to load the album then seemingly drops it)? It does work if I replay an album from the Now Playing > Player zone area, but not from Panes or custom views (e.g. my custom panes view).

I'll be sure to retest with the next build, for sure.

Also...

Next build will have this:
Changed: Switched the cap for memory plabyack track loading to 2GB on 32-bit and 16GB on 64-bit.

Nice! But what happens if somebody using the 64-bit build has less than 16GB of RAM, e.g. 8GB or something like that? Is it adaptive to actual available system memory?

[blgentry]

So it does little to fix gapless playback on a slow disk/network.

You've been asking about this for a very long time now.  What's your special use case that makes this such a big deal for you?

Brian.

[RD James]

You've asking about this for a very long time now.  What's your special use case that makes this such a big deal for you?

I don't know about "special use case".
Media Center only allows for up to 20 seconds to load the next track for gapless playback - it's 6 seconds by default.
That's not always enough time to wake a disk or network connection and load the track, or if something else running on the system currently has that local disk at 100% usage and is causing the file to load very slowly.
 
I can't be the only person on here that actually uses their system for work and for other entertainment purposes like gaming, with music playing in the background, instead of building a PC completely dedicated to playing music and paying to run two PCs at the same time.
 
The primary goal of memory playback should be to ensure 100% uninterrupted gapless playback while using the minimum amount of memory required to do so. If it can't do that, you're just needlessly filling up RAM for the sake of it.
Queuing up more than just the next track and perhaps retaining the previous track or two are enhancements to that behavior which allows for instant track skipping, but gapless playback has to be working first.
 
With the current "album" system, it just falls back to loading tracks from disk directly for me.
The smallest smartlist I have produces a playlist with 71 tracks in it, and most are in the region of 100-400 tracks.
Play Doctor creates a list of 100 tracks.
 
I'm not asking for memory playback to support loading all 13GB / 400 tracks / 30 hours of music from one of those smartlists into memory - that would be a ridiculous waste of resources which has a significant impact on anything else running on the PC.
If it only queued up 3 tracks: the current and two upcoming tracks, and buffered a new track as the current finished, it would use about 100MB of RAM and all but guarantee that playback would be 100% gapless, as it gives it ~6-10 minutes to buffer that track on average - instead of using 13GB to accomplish the same thing.
That's why I proposed a minimum of two upcoming tracks and a buffer of up to 20 minutes. It probably doesn't need to be anything like that size, but having it fill some kind of duration instead of a limited number of tracks ensures that two very short tracks don't play one after the other and cause you to wait for it to buffer the third track after them. You could probably drop that to a guaranteed buffer of 5 or 10 minutes and it would be perfect.

[blgentry]

I don't know about "special use case".
Media Center only allows for up to 20 seconds to load the next track for gapless playback - it's 6 seconds by default.
That's not always enough time to wake a disk or network connection and load the track, or if something else running on the system currently has that local disk at 100% usage and is causing the file to load very slowly.
 
I can't be the only person on here that actually uses their system for work and for other entertainment purposes like gaming, with music playing in the background, instead of building a PC completely dedicated to playing music and paying to run two PCs at the same time.

Sure, I use my system for lots and lots of things while music is playing.  I've almost never had system activity interrupt the ability to play the tracks.  Do you have some really slow wireless NAS or something?  Or do massive file copies routinely on local disk that saturates it?  It just doesn't make sense to me.
 

The primary goal of memory playback should be to ensure 100% uninterrupted gapless playback while using the minimum amount of memory required to do so. If it can't do that, you're just needlessly filling up RAM for the sake of it.

I can mostly agree with this.  It just seems to be sort of complex or JRiver's staff would probably already have implemented a queue based system that, as you said, simply fills the queue when it reaches N% empty.  For example, when it's more than 25% empty, fill the queue again.  Or maybe this is just too much of an edge case that very few customers find to be a problem for them, so they've never spent the engineering effort to get all cases covered.  <shrug>

Brian.

[RD James]

Sure, I use my system for lots and lots of things while music is playing.  I've almost never had system activity interrupt the ability to play the tracks.  Do you have some really slow wireless NAS or something?  Or do massive file copies routinely on local disk that saturates it?  It just doesn't make sense to me.

Video work often has HDDs running at 100%. Even JRiver's audio analyzer will do it.
Portable USB drives sleep frequently - often enough to have gone to sleep by the time a track finishes - and can be slow enough when spinning up and loading a file that they don't manage to load the file in memory in <20 seconds.
Network is generally less of a concern for me unless there is another large file transfer going on while music is playing. Someone else mentioned streaming from cloud-based storage.
I mainly use JRemote when I'm outside of my network, but I could see it potentially being an issue for a remote client too.
 

I can mostly agree with this.  It just seems to be sort of complex or JRiver's staff would probably already have implemented a queue based system that, as you said, simply fills the queue when it reaches N% empty.  For example, when it's more than 25% empty, fill the queue again.  Or maybe this is just too much of an edge case that very few customers find to be a problem for them, so they've never spent the engineering effort to get all cases covered.  <shrug>

It just seems like the thing you do first is give tracks more than 20 seconds to buffer, before you start working on decoding full tracks into memory or filling a queue of no more than 15 tracks in memory.

[RD James]

Well I still don't understand why anyone would want to load up 16GB of audio, but 23.0.61 was supposed to increase the limit to 30 tracks and 16GB of memory. I'm seeing some unexpected behavior.
 
I added 30 tracks which total 14.0 GB in size - and these are individual tracks, not tracks which are part of an imported track+cue file.
When adding these tracks to the playing now list, MC was unresponsive for 5 minutes.
It appeared to load load 20 tracks, hit 14.4GB memory usage (somehow - the first 20 tracks total 10.4GB) and then dumped everything out of memory, resorting to playing directly from disk.

[RD James]

Bump.

[F Ribeiro]

64-bit memory playback with "load full album" is working for me with APE and up to 96 kHz FLAC files.

I have a separate drive with only the music on it. With an album of 88.2 kHz FLAC files it took 62 seconds before disc activity ceased. Memory usage for JRiver is at 1.67 GB. I then tried an album of 96 kHz FLAC files and it also took 62 seconds before disc activity ceases. Memory usage is at 1.2 GB. It shows it is reading all the album files during the 62 seconds.

192 kHz FLAC files are not loaded into memory.

I have album folders and JRiver processes excluded in Windows Defender. I also disabled real-time protection for the testing.

How did you exclude JRiver processes in Windows defender?

[mojave]

How did you exclude JRiver processes in Windows defender?

There are instructions on the wiki:  https://wiki.jriver.com/index.php/Taming_Windows_Defender

[AndrewFG]

I've reported elsewhere that I experience two issues with whole album memory playback. Namely..

1) UI freeze when loading the tracks. => Perhaps MC isn't doing the loading on a separate thread?

2) It fails to fetch the album art for playing now. => Perhaps there is a time out on the art fetch from disk due to the UI freeze? Or perhaps MC is confused about whether to load the art from the disk image or the memory image?

[Matt]

I've reported elsewhere that I experience two issues with whole album memory playback. Namely..

1) UI freeze when loading the tracks. => Perhaps MC isn't doing the loading on a separate thread?

2) It fails to fetch the album art for playing now. => Perhaps there is a time out on the art fetch from disk due to the UI freeze? Or perhaps MC is confused about whether to load the art from the disk image or the memory image?

The UI will be unresponsive while it loads the collection of tracks.  I suppose it could show a wait message, but I'm not sure that's better?  My work machine loads the tracks in a second or two, but maybe if there's a slow drive?

I don't think I can reproduce the problems with album art.  I load an album and it shows the art with no problem.

[dtc]

The UI will be unresponsive while it loads the collection of tracks.  I suppose it could show a wait message, but I'm not sure that's better?  My work machine loads the tracks in a second or two, but maybe if there's a slow drive?

I don't think I can reproduce the problems with album art.  I load an album and it shows the art with no problem.

It takes 2 minutes to load a 4 GB DSD from an external usb 2 drive. A Redbook albums takes less than 10 seconds from the same drive.

[RD James]

The UI will be unresponsive while it loads the collection of tracks.  I suppose it could show a wait message, but I'm not sure that's better?  My work machine loads the tracks in a second or two, but maybe if there's a slow drive?

I think Andrew's request was to load the tracks in a separate thread so that it doesn't freeze the UI or prevent you from using the player while the tracks are loaded into memory.
If displaying a message would prevent Windows from thinking the player has crashed, that's at least an improvement, but it doesn't really do anything to solve the problem of playback taking so long to start with large files or many tracks over a slow connection.
As I said above, it froze the player for five minutes when I tried to load 14GB of music - and after all that it failed after 20 tracks, which caused it to revert to playing the tracks from disk anyway!
 
I think this form of "album" playback is badly flawed, and makes the playback experience in Media Center much worse when enabled, rather than being an improvement.
Every change that is made to memory playback seems to be another placebo for audiophiles, rather than focusing on actual real-world performance issues that memory playback could solve.
This album feature does little to help playback from a slow/busy drive or network connection since you have to wait for it to load as many as 30 tracks into memory over that slow connection before it even begins.

[AndrewFG]

The UI will be unresponsive while it loads the collection of tracks.  I suppose it could show a wait message, but I'm not sure that's better?  My work machine loads the tracks in a second or two, but maybe if there's a slow drive?

I don't think I can reproduce the problems with album art.  I load an album and it shows the art with no problem.

In my case loading a typical CD quite often causes Windows to bring up its standard dialog "The application has become unresponsive. Close or Wait?" My HTPC has the music tracks on an internal HD (albeit of the spinning disk variety) and the OS and MC on an SSD so it's not a disk latency issue per se. Running Windows 10 and Norton AV.

[Matt]

Coming next build:
Changed: When loading tracks for album memory playback, a wait message will display if it takes more than one second.

[JimH]

In my case loading a typical CD quite often causes Windows to bring up its standard dialog "The application has become unresponsive. Close or Wait?" My HTPC has the music tracks on an internal HD (albeit of the spinning disk variety) and the OS and MC on an SSD so it's not a disk latency issue per se. Running Windows 10 and Norton AV.

Could you test without Norton?  There's no need to check media files for viruses.

[AndrewFG]

Jim, I could certainly test without Norton, and I will. However there is no way I am going to accept turning off my AV as a necessary requirement for running MC. Nor indeed should you think to be so irresponsible as to recommend that to others.

[JimH]

I'm only suggesting that you test without antivirus, uninstalling even.  I've never suggested that anyone should run without antivirus software.

However, there is no reason that I know of for any AV software to check every media file as it is opened.  I don't believe a media file can ever pose a threat. 

[RD James]

I'm only suggesting that you test without antivirus, uninstalling even.  I've never suggested that anyone should run without antivirus software.
However, there is no reason that I know of for any AV software to check every media file as it is opened.  I don't believe a media file can ever pose a threat.

Anything is a potential threat.
libFLAC 1.3.0 Stack Overflow / Heap Overflow / Code Execution
Microsoft Windows Media Format MP3 Metadata Remote Code Execution Vulnerability

[Hendrik]

Nevertheless, its no excuse to give "AntiVirus" applications free reign over your entire system. Many of those "advanced" protection things are typically more invasive then your ordinary virus, and cause an equal amount of issues (and in some cases even increase the risk of being vulnerable)

We don't recommend people to get rid of them, but we do recommend testing without them if an odd/unexplainable bug shows up, and there have been *a lot* of documented cases where this revealed the cause.

[JimH]

Anything is a potential threat.
libFLAC 1.3.0 Stack Overflow / Heap Overflow / Code Execution
Microsoft Windows Media Format MP3 Metadata Remote Code Execution Vulnerability

I'm more worried about meteors.

[AndrewFG]

Could you test without Norton?  There's no need to check media files for viruses.

Ok. I have tested it fully. I can confirm that the bug is repeatable. And consistently leads to an MC application freeze every time. Conditions are as follows..

- MC 64 bit
- Windows 10
- MC in Theater View
- MC memory playback "load full album non decoded into memory"
- Track formats M4A Apple Lossless (so quite big files)
- In MC Theaterview browse to an album, select, play, play all => tracks start to play
- In MC Theaterview browse to a second album, select, play, play all, => MC freezes
- It makes no difference if AV is turned on or off
- Tracks are on a built in hard disk, so minimal latency
- After MC application freezes, it shows 0% CPU in task manager
- Task manager command to terminate MC doesn't => reboot required
- If MC memory playback is turned off, it all works fine..

[JimH]

Is that with Norton uninstalled?  Sorry, but it's the only way to eliminate it.

[AndrewFG]

I am not going to uninstall Norton. I turned all of its protection off. This is a bug in MC not in Norton.

[JimH]

It certainly may be, and we will try to reproduce it, but ... we have seen _many_ cases in which antivirus software caused problems, even when it was disabled.

[Matt]

Ok. I have tested it fully. I can confirm that the bug is repeatable. And consistently leads to an MC application freeze every time. Conditions are as follows..
- In MC Theaterview browse to an album, select, play, play all => tracks start to play
- In MC Theaterview browse to a second album, select, play, play all, => MC freezes

This is interesting because when you start the second album from Theater View, it purges all the first album's files from the memory cache.

So for me testing the memory usage from album to album stays about the same.

[AndrewFG]

Yup. The first album played in TheaterView always loads and plays. And the second album played thereafter in TheaterView always freezes MC. Obviously I could not say what would happen with any subsequent album since I always have to reboot th PC at that point.