INTERACT FORUM
More => Old Versions => JRiver Media Center 26 for Windows => Topic started by: Jamil on June 20, 2020, 07:03:30 am
-
I am noticing bizarre behavior that is probably a remnant of the later added file played from memory feature. Why is MC26 holding locks on the currently played file when it had been completely loaded into memory? This doesn't make lots of sense to me. Perhaps developers here can share insight on why you are doing this.
I am playing a FLAC file where I have the option set to play the decoded file from memory. In order to do this, the entire file must be read and loaded into memory. After it is loaded and while the track continues to play, you are keeping a lock on the file. When I change the rating of the file currently being played, I see 'Saving tag changes' on the status bar until the playback completely finishes. This does not make a lot of sense, since the file in its entirety has been 100% loaded into memory. I am requesting that you close the file after you are finished loading it into memory.
Can you please fix this?
-
I'll look at this Monday. It's possible the plugin keeps the file open even if it finds it in memory.
-
That reminds me since this is related (and kinda the reverse because memory playback 'fixes' it), I don't suppose this is possible without using memory playback too? This is the only reason I use memory playback, because while playing the files normally (without memory playback) they appear "locked" to the system and metadata in Windows Explorer disappears while the file is playing, which can actually throw off my directory comparison software into thinking the file's changed because it's locked and in use.
As far as I know, other media players like foobar2000 and MPC-HC won't "lock" the file while playing and metadata from Windows Explorer doesn't appear to 'disappear' while playing, it'll still appear as readable by the system, of course you're not able to rename or delete the file(s) because they're in use, but they're also not locked by the system (e.g. you can open the same file multiple times at the same time).
Here's what I mean...
Here's an example of an album that's shown normally in Windows Explorer with metadata info being shown: https://i.imgur.com/GvLXuWP.png
And here's what happens if you play a song from the album shown in MC without memory playback enabled (and pressing F5 in Windows Explorer while the track is replaying to force refresh the Windows Explorer window): https://i.imgur.com/WhPLZ4p.png
You'll see the first track's metadata will 'disappear' in Windows Explorer while it's playing in MC. Why does this happen? It doesn't in other media players - if that could be solved, I wouldn't need to use memory playback anymore. :D
-
MC does in fact not lock reading or writing files during playback. I can play a music file and then open it in a random editor and just mess around in it, and save it just fine. Deleting/Renaming is locked just by virtue of the file being open, but reading/writing is not limited.
It would be a bad idea to modify a file while its being played, but MC is not prohibiting that - its only stopping itself from writing to open files.
For memory playback -
The "Load full file (not decoded) into memory" mode should already close the file after it loaded it into memory as far as I can tell. The decoded mode will not, so use the "not decoded" mode when you desire that behavior.
-
Fair enough (I already used the full file not decoded memory playback option too), but I'm still curious why the metadata in Windows Explorer seems to disappear/not show when playing back the music file in MC without memory playback like my screenshots show? It doesn't happen with any other media player app and IMO, that actually shouldn't happen.
-
Doesn't happen here. It shows fine in the explorer overview, and i can go to properties -> details and it shows there too.
-
It only appears in Windows Explorer if you force refresh the folder using F5 while it's playing the file. Without the force refresh it'll appear normal.
I'd be interested to know if anyone else can easily reproduce it like I can.
-
MC does in fact not lock reading or writing files during playback. I can play a music file and then open it in a random editor and just mess around in it, and save it just fine. Deleting/Renaming is locked just by virtue of the file being open, but reading/writing is not limited.
My experience has been that this actually is not true. I historically have never used MediaCenter to write tags to any files. After learning how to turn off all the noise it adds to tags by default, I am now no longer setting my media library to read only while MediaCenter plays media files. I am even now allowing it to update my tags.
My findings are that any file MediaCenter is currently playing cannot under any circumstances be modified by my external tag editor. As soon as the file stops being played, only then may my tag editor successfully write the tags. MediaCenter is somehow keeping a lock on the file while it is being played. If a file handle is open during play, that will force a lock. Closing the file and releasing the handle releases the lock.
-
It only appears in Windows Explorer if you force refresh the folder using F5 while it's playing the file. Without the force refresh it'll appear normal.
I'd be interested to know if anyone else can easily reproduce it like I can.
AD, metadata retrieval in explorer works fine for me while the file is playing.
However, I'll point out this is the sort of thing that could easily be affected by the specifics of the situation (file system type, (ntfs vs exfat), network share vs local storage, optimized for speed vs quick removal, all those sorts of things
But for me it worked fine on locally attached non removeable ntfs under Windows seven.
-
I think it's a Windows 10 only sort of deal and I'd actually be surprised if it happened in Windows 7 or 8.1. I can reproduce it in a brand spanking new Windows 10 2004 virtual machine with only MC installed (and Defender tamed, of course). The easiest way to reproduce it is to start playing a FLAC file that's been imported into MC (obvious the files would need proper metadata ahead of time before importing) then selecting the On Disk (external) option while playing back media. It should open Windows Explorer to the media's folder and it *should* appear like in my screenshot, 'missing' metadata in Windows Explorer while playing back the FLAC file.
-
"Screenshots or it didn't happen" -- anon.
(https://dl.dropboxusercontent.com/s/6sb43dl6qve8jxu/mc26_currently_playing.png)
(https://dl.dropboxusercontent.com/s/kaz3m0gwfvfl4ti/mc26_locks_currently_playing_file.png)
-
Thinking about it, I bet what I'm seeing in Windows Explorer is related to your issue too. Does it only happen with the file you're currently playing? Meaning, does it work as expected with any of the other files on the same album except the one being played? If so, likely the same thing is causing what I'm seeing with Windows Explorer.
-
This issue only happens to the currently played file. No other file has this issue.
-
Which app is that you're using to edit tags? I wanna give it a go myself and see what happens. I'd also be interested to see if you see the same Windows Explorer thing (if you're using Windows 10, in Windows Explorer you have to make sure the details view in Windows Explorer is being used like in my screenshot above).
-
Latest version downloadable from here: https://www.softpointer.com/tr.htm
The trial may work for a limited time for test purposes.
Note that this is a network share I am playing from.
-
Depending on how an external app might work, the lock may prevent it from tagging it. A sane writing application would try to get an exclusive lock so that unexpected stuff is avoided - and since MC has the file open, exclusive locks are not possible, since you can't throw someone out that is already in.
But it most definitely wont prevent anyone from reading, as AD seems to experience.
-
My question is why does MC26 have any type of lock whatsoever on a file that is loaded 100% into memory? I still am not seeing a logical explanation for this.
Matt stated that a plugin may be the culprit. Is this a plugin that JRiver owns, or is it a third party?
My request is to stop locking files with any type of lock whatsoever for a file that is in memory.
Does this now make sense?
-
Incidentally, I saw blame of the application being at fault for attempting to take exclusive use of the file.
MC26 also shares this same issue of not being able to update the rating of currently playing files as I previously stated.
Finally, Windows Explorer also cannot write to the file that MC26 is playing from memory:
(https://dl.dropboxusercontent.com/s/gs76teqlw7ryi6h/mc26_locks_currently_playing_file_explorer.png)
Is this a bug? No.
This is working per design. I am questioning the logic of that design.
This is a feature request.
-
Could you eliminate the NAS in your testing?
-
Issue reproduced on local D: drive:
https://dl.dropboxusercontent.com/s/z7h0xku90strzj8/mc26_currently_playing2.png
https://dl.dropboxusercontent.com/s/bgdv1849loav8tl/mc26_cannot_write_rating_change.png
https://dl.dropboxusercontent.com/s/makkpe81mcz5i9v/mc26_locks_currently_playing_file_explorer2.png
-
MC won't let you mess with the tags but mp3tag is quite happy to alter the tags of a playing file using load undecoded file into memory for playback.
-
Thanks for this info.
How did you get mp3tag to update the file's tags in MC26?
When I try, I get an error:
(https://dl.dropboxusercontent.com/s/p17mkecss95qxg0/mp3tag_locked_file.png)
-
I just played some trusty Abba with "Load full file (not decoded) into memory" and I deleted the file as it was playing.
That is what I would expect, and it seems to be working for me.
-
That's interesting. I cannot delete the playing file at all with a file is in use error.
-
I played APE files. Could it be file type specific?
-
I tried to delete while playing a FLAC. Let me find an APE file and attempt to delete.
I played an APE file and Windows Explorer would not allow me to delete while the file was playing.
I am running version 26.0.91.
I can try a different version perhaps?
-
Are you in the same memory mode I posted?
-
I had it set for full file decoded.
I switched it to full file not decoded and I was able to successfully delete the file while it was playing. That is the difference. It has to do with full file decoded versus full file not decoded.
-
Decoded needs to lock the file. That's to be expected.
-
I always thought that "decoded" meant it decode the full file and that the full decoded data was loaded into memory. Sounds like you are saying that the file is kept open and pieces of the file are decoded and loaded into memory throughout the playing of the track. So, the decoded option has disk activity throughout. The not decoded options say "full" whereas the decoded option does not use the word full. If that is how decoded works, it is not what I expected.
-
Hi Matt,
Can you explain to one of the plebian classes why load decoded file into memory requires locking of the file?
-
Decoded won't go back to the disc if you don't do anything special - and the amount of memory is enough to keep the remainder of the file.
But if you seek, it'll have to hit the file, because we remove audio from memory that was already played out so that we can support long files and don't needlessly consume extra memory for data that 99% of cases wont be needed again.
The way most input plugins work, if the file were to change after we initially read the header information and whatnot, seeking would have a chance to go wrong. We definitely don't want that. And thats why we keep the file open to ensure we can access it in the same way as it used to be. MC won't access it unless you ask it to by seeking.
-
Thank you very much Hendrik this poor plebian soul now understands clearly the reasons for the lock under those conditions.
Learning is the way to stay young in mind.
-
Hendrik - So loading decodied into memory actual does load the FULL file, even though the word full is not in the option.
Do decoded (full file and full album) also clear memory as they play and therefore keep the file open?
-
"full file" refers to loading the file in its entirety from the disc without parsing it first - and then parsing it from memory.
Decoded mode obviously decodes the file as its reading it, so the "full file" as-it-was on the disc is never entirely in memory - the decoded audio is.
The full file "not decoded" mode will always load the entire file first, close the original, and only then start playing, so it can avoid any complications of switching between different locations of reading the file from etc. This memory is only free'ed after the entire file is done playing.
The "decoded" modes will start decoding audio until either the file is done or the memory is full (or our usage limit exceeded), in which case it'll wait until some audio has played out, which gets free'ed, and then load more. If the file is short enough, or there is enough memory, the entire audio of the file might be in memory at one time.
The difference in behavior is from the potentially vast size difference between encoded and decoded audio. But also from the architecture of how playback simply works.
"Full file (not decoded)" mode is IMHO a much better option to use. It avoids disc access and any problems from that, and uses much less memory.
-
Thanks.
Does loading the full album not decoded also keep all the files open throughout the playing of the album? The album load will typically be larger, even encoded, that a decoded single track.
-
Thanks.
Does loading the full album not decoded also keep all the files open throughout the playing of the album? The album load will typically be larger, even encoded, that a decoded single track.
We load the full album and close the files right after. They should not be locked.
I kind of like using the decoded approach because then the bits for APE and WAV are perfectly identical after a couple seconds so you just could never argue there was any difference.
-
We load the full album and close the files right after. They should not be locked.
That's what I thought. Given a a decoded file is usually smaller than a encoded album, I would think that decoded would work the same as full album, but it seems decoded keeps the file open for seeking purposes. I guess the question is whether all three modes discard some of the in memory data as it plays and therefore may require going back to the file if a seek to a previous position occurs. Still confused as to why decoded file would keep the file open when full album does not. Not sure what I am missing.