More > JRiver Media Center 31 for Linux
Playing an album took almost 20 seconds to start
bob:
You've got some odd things going on with your network. For example:
5071325: 140392322287168: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Finish (30878 ms)
5071325: 140391550547520: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Finish (30146 ms)
Those are 2 different threads with 30 second delays
You are playing local material on a local output device right?
Try disabling media network and see what happens.
Also if you want to see thread priorities during playback you can do this:
ps -T -eo pid,tid,class,rtprio,ni,pri,comm | grep MediaCenter
From a terminal.
avid:
Thanks.
I didn't spot those long (30+s) delays. But they may not be relevant because they occur after the music starts playing - and when it eventually starts, it always plays fine.
I did notice an awful lot of SSDP traffic in the log, But while there are multiple MC servers on the net, each has its own library, with local content and played though the local audio device. DLNA is enabled but not used. And the AVR has (unused) DLNA render capability too. I could perhaps turn off all three DLNA roles in MC.
Unfortunately it would be very difficult to disable the media network altogether. A single switch seems to enable everything, and I need MCWS for its control access. That MC can't really be used with the desktop UI only. And as the pauses only seem to happen every few albums, I need to track the occurrences in a normal working situation. Attached are my media network settings.
Annoyingly, this problem only occurs on the "live" domestic media machine (recently moved from Windows to Linux). It didn't happen on Windows, and doesn't on my main desktop dev/test/everything machine (also Windows). I'll spin up a Linux test machine by my desk and try experimenting with that - I can disable the media network on that one.
This may take some time!!
avid:
I have now added code to my live software which:
* Notes the time at which I request to play an album
* On my regular 2 second poll, if it has not started playing within 2 seconds, I log the MC threads using the options you suggest
* Once it does start playing (which it always will eventually), if it has taken more than 10 seconds I attempt to preserve a copy of the MC Log.txtThis allows me to have the evidence of occurrences of the problem when I am not there or can't immediately deal with it.
It happened yesterday afternoon, and here are the logs from that.
Maybe we will eventually detect what activity in the log is significant
avid:
And it has happened again this morning - logs attached.
I see that I have to be careful when copying the Log.txt as there seems to be a large unsaved in-core buffer. I am now allowing 10 seconds for the log to flush to the file. I will have to see if that is long enough. Is there any MCWS way to cause the logs to flush?
Let me know if there is additional logging or other info you want me to collect.
avid:
And the next album did it as well - the issue is more frequent than I realised. And waiting 10 seconds was not enough for the MC log to flush to disk. I shall try 30 seconds.
Further logs attached. I shall stop sending logs now unless you ask for more info.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version