INTERACT FORUM
Linux => JRiver Media Center 31 for Linux => Topic started by: mattkhan on June 07, 2023, 05:17:12 pm
-
this is a v peculiar possible bug
this only happens on linux, repeating the same on windows does not cause a problem
this only happens (for this specific value) with this file
for me, this is perfectly reproducible
* File > Open Media File > pick the attached file
* (optional) press pause (easier to see what position you hit but the same behaviour occurs whether paused or not)
* set the position
curl "http://127.0.0.1:12345/MCWS/v1/Playback/Position?Position=99999&Zone=-1&Token=xyz"
* works fine
* set the position again
curl "http://127.0.0.1:12345/MCWS/v1/Playback/Position?Position=100000&Zone=-1&Token=xyz"
* playback immediately ends
* start it again
curl "http://127.0.0.1:12345/MCWS/v1/Playback/Position?Position=100000&Zone=-1&Token=xyz"
* now it works fine
curl "http://127.0.0.1:12345/MCWS/v1/Playback/Position?Position=100000&Zone=-1&Token=xyz"
* playback ends again
basically it's just broken but I do not know if that is something about the length of the file that makes some bug easier to exploit. Certainly it makes it impossible to use this API call on this OS atm if it may spontaneously stop playback.
-
this file is 6m 47s long (407s long)
the same behaviour occurs at approx the 360s mark
this is also ~89% of the way through the track
this could be coincidence but behaviour is repeatable so suggests a bug to me
-
using the above 407.mp4 file, this does not fail completely deterministically (i.e. at the same ms) but the test does fail 100% of the time, i.e. playback abruptly terminates
for i in {60..99}; do curl "http://127.0.0.1:52129/MCWS/v1/Playback/Position?Position=3${i}001&Token=xyz"; sleep 1;curl "http://127.0.0.1:52129/MCWS/v1/Playback/Position?Position=3${i}001&Token=xyz";sleep 1;done
-
tried a file 25:19 long (1519000ms), reliably dies around the ~148s mark (so about 30s to go)
-
sample log
66234449: 140519353075392: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Start
66234449: 140519353075392: Sharing Plugins: CHTTPListenerWorker::HandleRequest: TCP: 127.0.0.1: GET: http://127.0.0.1:52129/MCWS/v1/Playback/Position?Position=1489001&Token=xyz
66234451: 140519353075392: Sharing Plugins: JRWebService::Process: Start
66234452: 140519353075392: Sharing Plugins: JRWebService::Process: URL: /MCWS/v1/Playback/Position?Position=1489001&Token=xyz
66234452: 140519353075392: Sharing Plugins: JRWebService::Process: Finish (0 ms)
66234452: 140519353075392: Sharing Plugins: VHTTPMessage::Write: Wrote 133 bytes
66234453: 140519353075392: Sharing Plugins: CHTTPRequestMessage::ReadPreamble: Failed to read Method
66234453: 140519353075392: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Finish (3 ms)
66234453: 140519353075392: General: CReferenceCountedSocket::Close: SOCKET_DEBUG: closesocket() closing 44
66234467: 140524465092544: Playback: COSDWindow::Show: Start
66234467: 140524465092544: Playback: COSDWindow::Show: , -1, 0
66234470: 140524465092544: Playback: COSDWindow::UpdatePosition: Start
66234488: 140524465092544: Playback: COSDWindow::UpdatePosition: New position 0, 0, 0, 0
66234488: 140524465092544: Playback: COSDWindow::UpdatePosition: Finish (18 ms)
66234488: 140524465092544: Playback: CDisplayWnd::NotifyOSDHeight: Start
66234492: 140524465092544: Playback: CDisplayWnd::NotifyOSDHeight: New position 5, 389, 929, 993
66234492: 140524465092544: Playback: CDisplayWnd::NotifyOSDHeight: No OSD
66234492: 140524465092544: Playback: CDisplayWnd::NotifyOSDHeight: Finish (4 ms)
66234492: 140524465092544: Playback: COSDWindow::Show: Finish (25 ms)
66234492: 140524465092544: Playback: CJRVideoEngine::Seek: Start
66234495: 140519560660672: Playback: CJRVideoEngine::Thread: End of file reached.
66234506: 140519560660672: Playback: CJRVideoEngine::PerformSeek: Start
66234506: 140519560660672: Playback: CJRVideoEngine::PerformSeek: Finish (0 ms)
66234593: 140524465092544: Playback: CJRVideoEngine::Seek: Finish (100 ms)
66234594: 140519552267968: Playback: CJRMediaStreamVideo::Decode: Error receiving frame (-541478725)
some internal overflow?
-
it's definitely not a bad position because I restart playback and send a single position (bigger than the one that failed)
66574517: 140519216756416: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Start
66574517: 140519216756416: Sharing Plugins: CHTTPListenerWorker::HandleRequest: TCP: 127.0.0.1: GET: http://127.0.0.1:52129/MCWS/v1/Playback/Position?Position=1499001&Token=xyz
66574520: 140519216756416: Sharing Plugins: JRWebService::Process: Start
66574520: 140519216756416: Sharing Plugins: JRWebService::Process: URL: /MCWS/v1/Playback/Position?Position=1499001&Token=xyz
66574521: 140519216756416: Sharing Plugins: JRWebService::Process: Finish (0 ms)
66574521: 140519216756416: Sharing Plugins: VHTTPMessage::Write: Wrote 133 bytes
66574522: 140519216756416: Sharing Plugins: CHTTPRequestMessage::ReadPreamble: Failed to read Method
66574522: 140519216756416: Sharing Plugins: CHTTPListenerWorker::HandleConnection: Finish (4 ms)
66574522: 140519216756416: General: CReferenceCountedSocket::Close: SOCKET_DEBUG: closesocket() closing 35
66574530: 140524465092544: Playback: COSDWindow::Show: Start
66574530: 140524465092544: Playback: COSDWindow::Show: , -1, 0
66574533: 140524465092544: Playback: COSDWindow::Show: Creating OSD window
66574542: 140524465092544: Playback: COSDWindow::UpdatePosition: Start
66574563: 140524465092544: Playback: COSDWindow::UpdatePosition: New position 0, 0, 0, 0
66574563: 140524465092544: Playback: COSDWindow::UpdatePosition: Finish (21 ms)
66574563: 140524465092544: Playback: CDisplayWnd::NotifyOSDHeight: Start
66574566: 140524465092544: Playback: CDisplayWnd::NotifyOSDHeight: New position 5, 389, 929, 993
66574566: 140524465092544: Playback: CDisplayWnd::NotifyOSDHeight: No OSD
66574566: 140524465092544: Playback: CDisplayWnd::NotifyOSDHeight: Finish (2 ms)
66574566: 140524465092544: Playback: COSDWindow::Show: Finish (36 ms)
66574566: 140524465092544: Playback: CJRVideoEngine::Seek: Start
66574571: 140519543875264: Playback: CJRVideoEngine::PerformSeek: Start
66574571: 140519543875264: Playback: CJRVideoEngine::PerformSeek: Finish (0 ms)
66574612: 140524465092544: Playback: CJRVideoEngine::Seek: Finish (45 ms)
works fine
definitely an MC bug
-
repeated same tests using same files on windows,completes successfully 100% of the time so clearly a linux MC bug
-
It's a video file?
-
Yes, attached to the posts above. Plays normally from start to finish without issue.
-
Yes, attached to the posts above. Plays normally from start to finish without issue.
Oh I see.
Are you using direct-x on windows in MC?
That of course would be a different path through the playback engine.
-
JRVR in each instance on Nvidia
the issue only occurs when using the mcws call. For me, the procedure I posted is 100% reproducible and requires no additional setup, just open file and run the command.
-
Ok, I'll take a look when I get a chance.
Bump this if you don't hear back in a while.
-
ok thanks
problem also occurs with the legacy opengl renderer btw (thought I'd try it just to eliminate jrvr as a cause)
-
using the file from the OP
I created a new longer file
$ cat t.txt
file '112.mp4'
file '112.mp4'
$ ffmpeg -y -f concat -safe 0 -i t.txt -c copy 112112.mp4
and then repeated the same test using that file
completed normally without error
hopefully this is reproducible and enough to be able to quickly hone in on where the problem is
-
same procedure works for the 407 file I posted
problem appears to be driven by position relative to file length
-
I think it does affect windows after all - https://yabb.jriver.com/interact/index.php/topic,136266.0.html
-
I think you can disable stop on long pause to confirm if thats the only thing thats going on. I wouldnt think your test case is long enough to trigger it.
-
I agree & also it seemed too repeatable on specific values to be that problem on linux. I'll retest to be sure.
-
ok it's definitely not that problem on linux so back to the problem being something specific to linux MC
-
there appear to be significant differences between windows and linux when it comes to how it reacts to video commands
this is in relation to https://yabb.jriver.com/interact/index.php/topic,135756.0.html
https://github.com/3ll3d00d/displaycal-py3/blob/mcws-untethered/DisplayCAL/mcws.py
this works without issue on windows but appears to be a problem on linux
-
actually, sorry, it's just a reflection of the same set position problem. In this case I was testing with a video that is 2s long and even setting position to 201, for such a short file, makes it blow up.
-
This should be fixed in the next build.
-
Great, thanks.