clsid2 / mpc-hc

Media Player Classic
GNU General Public License v3.0
11.22k stars 494 forks source link

Player close the streaming video after seeking in. #2217

Closed Raziel-SSJ closed 1 year ago

Raziel-SSJ commented 1 year ago

Hi there.

I've a very annoying issue where streaming video playback cuts off after seeking. After seeking, MPC seems to buffer but often close the video immediately after. It seems to happen randomly but often in the same places.

I've tried several things but couldn't find a solution and I'm wondering if this is an MPC with key-frames related issue or server related issue.

A workaround is to pause the video before seeking to prevent the player from closing the video, then advance frame by frame. If it is possible to advance frame by frame, then the video can be played back, but if it is not possible (fixed image) then the video will close if played back. Strangely enough I can predict it with task manager since, when this happens, the download speed goes to 0 while trying to buffer after seeking.

Do you have any idea please? Or is there a way to make MPC to try reloading the video where it was before (or the previous key-frame) when this happens?

Ask me if you want a link to a video.

Thanks.

clsid2 commented 1 year ago

The player does not close videos by itself. I assume you means it stops the video. If that happens it means that the end of stream has been reached or there is a server issue.

You can use Ctrl+E to reload video.

Raziel-SSJ commented 1 year ago

The player does not close videos by itself.

Sorry, I forgot to mention I've set the "Playback"->"After Playback" option to "Close" in settings. So:

So you are right, I should have said "It acts like it's reached the end of the stream/video", but the thing is that I did not reach the end of the stream.

Crtl+E is what I'm currently doing, but reloading and finding the precise moment where I was without having to do it again is very painful in the long run, especially when it happens several times in a row. This happens relatively often.

I also forgot to mention that this happens because I often go back 10 seconds in the stream and so the player has to reload the stream, which is also annoying because it's long for big files.

So, if there is no possibility to make the player automatically reload the stream by itself when this happens, having the ability to keep the last 10 or 30 seconds cached and not having to reload them would be even greater and would probably also prevent this behavior from happening.

Thank you for giving me your time.

clsid2 commented 1 year ago

The player has an option to remember playback position.

It doesn't know why it ended/failed so automatic reload is not possible. I am also not interested in offering such functionality.

The internal splitter already buffers some data. But that does not solve any problem when stream fails due to server issues.

Raziel-SSJ commented 1 year ago

The player has an option to remember playback position.

Sadly the stream restart from the beginning so this doesn't help in this case :'(

It doesn't know why it ended/failed so automatic reload is not possible. I am also not interested in offering such functionality.

Sure, implementing automatic reload function that need a special detection system is not a very pertinent work. But the next point is probably more pertinent (and probably easier to do?) :)

The internal splitter already buffers some data. But that does not solve any problem when stream fails due to server issues.

Yes, but that's because it buffers data ahead (and not behind) isn't it? However, buffering past data would certainly do the trick. And moreover, I think that being able to go XX second back in the file without having to reload the stream could please or might interest many people.

May I please open a Request for this feature to see if people are interested? Or do you think this is not the right place and I should rather ask to the Lav Filters team instead?

Thanks again for your patience <3

clsid2 commented 1 year ago

The developer of LAV Filters will not implement a backwards buffer. So requests are pointless. That would not prevent or solve the stream failing anyway.

If you disable the internal HTTP source filter, then a source filter from Microsoft is used instead, which buffers the stream as a temporary file. At least if the stream is a remote file and not some kind of segmented stream.

Give example link that fails frequently.

Raziel-SSJ commented 1 year ago

That would not prevent or solve the stream failing anyway.

The issue does not occur when I read the file from my HDD or SSD. The failing only happens when I seek through a stream(ed) file and the player fetches from the server that portion of "broken" data. So why would he fail if the data are already buffered? I don't understand.

Give example link that fails frequently.

Almost every files have failing points with this host provider (and other ones) but try this and navigate around 00:02:34.000

clsid2 commented 1 year ago

If server stops responding to data requests, then the stream "ends" and playback stops after the buffer runs empty.

I have no problems with playing that stream. I have seeked several times and let it play for several minutes at multiple points.

Raziel-SSJ commented 1 year ago

If server stops responding to data requests, then the stream "ends" and playback stops after the buffer runs empty.

Sure, but strangely this rarely happens when I pause the playback (and so the buffering) and resume playback. Almost always when I seek through the file. But I'm probably biased on this and that's probably related to my intuition described below.

I have no problems with playing that stream. I have seeked several times and let it play for several minutes at multiple points.

This is very odd. My intuition tells me it's something to do with "too many requests to the server", because it usually doesn't happen on the first try and I have to do many seeks to get this to happen. (That's why I came up with the idea of a "backward" buffer, in order to minimize the number of requests to the server when seeking back for just a few seconds, and also save some bandwidth at the same time) But sometimes it happens even though I haven't made requests to the server for a while, and it always seems happens at the same timecodes and no others (but I'm maybe wrong on that last point). Sadly there is no log to confirm or infirm this. (I enabled logging in advanced settings, but I didn't manage to find the log file)

It annoys me so much when I can't figure out what could be wrong^^ but it seems to be a lot cause and I won't bother you any further with this issue.

So, thank you very much for your help and your patience. And thank you to the whole team for your great work maintaining and evolving this awesome player. Have a nice day.

Raziel-SSJ commented 8 months ago

Hi @clsid2. Just a short update to let you know.

I've switched to fiber connection (300Mbps vs 30Mbps VDSL before) and despite this issue is still occurring, it happens much less often so, as you mentioned, that should be a server related issue.

That's all. Have a good day and KUTGW. Cheers 🤗