More > JRiver Media Center 31 for Linux
Playing an album took almost 20 seconds to start
avid:
So far, so good ...
I disabled the option "Run auto-import in background", and am using MCC_IMPORT_AUTO_RUN_NOW only when my software needs it (often at 03:00 a.m.) . And so far I have not had long delays.
I shall leave the MC logging enabled for now, and I have added some of my own logging that would highlight any occurrences.
I will report back in a week or so if the problem has appeared to be gone.
bob:
Thanks for the report.
The import thread runs at the lowest priority and the playback runs at the highest priority so I'm not sure why you have the issue but your solution is perfectly acceptable.
avid:
Thanks Bob. I assumed that the threading works as you describe, and I have never noticed this issue on Windows for 10+years.
However, there were a couple of things in the log (the "Previous Log.txt") that looked odd to me.
One is "Found changes in FILE-BEING-PLAYED". This seems to trigger some sort of reloading (a complete re-import?). But nothing should have changed that underlying file. And it was picked at random to be played.
And the second is the huge number of synchronous entries "General: RunProgram: Running blocking command via popen: stat -fc %T '/ssd/Music/FOLDERNAME/'". There are tens of thousands of these, and even at just a few ms for each call, they soon add up! And would sub-processes inherit the import thread's low priority? Just asking!
So these pointers may be indicative of an underlying cause - over to you!
But I am no longer waiting for a fix, as my work-around seems to be fine.
bob:
--- Quote from: avid on September 19, 2023, 09:59:15 am ---Thanks Bob. I assumed that the threading works as you describe, and I have never noticed this issue on Windows for 10+years.
However, there were a couple of things in the log (the "Previous Log.txt") that looked odd to me.
One is "Found changes in FILE-BEING-PLAYED". This seems to trigger some sort of reloading (a complete re-import?). But nothing should have changed that underlying file. And it was picked at random to be played.
And the second is the huge number of synchronous entries "General: RunProgram: Running blocking command via popen: stat -fc %T '/ssd/Music/FOLDERNAME/'". There are tens of thousands of these, and even at just a few ms for each call, they soon add up! And would sub-processes inherit the import thread's low priority? Just asking!
So these pointers may be indicative of an underlying cause - over to you!
But I am no longer waiting for a fix, as my work-around seems to be fine.
--- End quote ---
A bit spammy but
General: RunProgram: Running blocking command via popen stat -fc %T '/ssd/Music/FOLDERNAME/'"
Just means it's scanning media files for changes. That happens upon filesystem changes if that's enabled otherwise once every 2 hours on a timer.
I should probably remove that to reduce the logging spam but it also makes sense to turn off logging if you aren't meaning to generate on to send.
avid:
There's still an issue here that feels like a thread priority one. I have just started playing an album and it took 20-22 seconds to start making a noise. And my 2 second poll of Playback/Info also showed no activity in that time.
I attach the tail end of the log. The file is "Sand In Your Shoes.mp3" starting at line 58 of the log.
There should be no auto-import happening, and I can't see any evidence of that.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version