Seeking in a film is not working in reverse mode

[pletexier]

Hi @euzu,

Seeking in a film is not working in Reverse proxy mode. I think this is the same problem as issue #82 .

Regards,

Patrice

[euzu]

@pletexier can you fünd out what url is called? it could be missing api implementation.

[pletexier]

I think the "range" header is ignored when loading the video file.

[2024-09-29T15:43:45Z DEBUG m3u_filter::api::api_utils] Try to open stream http://xxxxxxxxxxx:2082/movie/xxxxxxxxxxx/xxxxxxxxxxx/1113030.mkv [2024-09-29T15:43:45Z DEBUG m3u_filter::utils::request_utils] Ignoring request header host=192.168.xxx.xxx:8901 [2024-09-29T15:43:45Z DEBUG m3u_filter::utils::request_utils] Request headers {"user-agent": "Player LibVLC/3.0.18", "accept-language": "en_US", "range": "bytes=4242165-", "accept": "/"}

[euzu]

As you can see in the code the headers are forwarded: stream proxy

[euzu]

@pletexier i have tested it and i could seek forward and backward. There must be something different with your provider or client. We need to figure out what it is.

[euzu]

@pletexier do you have any updates regarding the problem?

[euzu]

@pletexier with the latest version some users reported that this is working for them. Can you confirm?

[euzu]

closed due inactivity

[jojo141185]

I am experiencing the same problem with the m3u-filter proxy. Depending on the player, the stream starts from the beginning or continues at the same point after a short pause. In comparison with iptv-proxy, seeking and skipping with the same stream works without any problems.

This is what I see repeatedly in the debug log of m3u-filter after trying to seek:

Player: IPTVNator

[2025-01-04T18:32:08Z DEBUG m3u_filter::api::xtream_api] Streaming stream request from http://myXtream.url/series/myUser/myPass/1753625.mkv
[2025-01-04T18:32:08Z DEBUG m3u_filter::api::api_utils] Try to open stream http://myXtream.url/series/myUser/myPass/1753625.mkv
[2025-01-04T18:32:08Z DEBUG m3u_filter::utils::request_utils] Ignoring request header host=192.168.2.10:8901
[2025-01-04T18:32:08Z DEBUG m3u_filter::utils::request_utils] Request headers {"accept-language": "de", "accept-encoding": "identity;q=1, *;q=0", "range": "bytes=0-", "user-agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) iptvnator/0.16.0 Chrome/118.0.5993.144 Electron/27.1.0 Safari/537.36", "accept": "*/*", "connection": "keep-alive"}

Player: VLC

[2025-01-04T18:34:18Z DEBUG m3u_filter::api::api_utils] Try to open stream http://myXtream.url/series/myUser/myPass/1753625.mkv
[2025-01-04T18:34:18Z DEBUG m3u_filter::utils::request_utils] Ignoring request header host=192.168.2.10:8901
[2025-01-04T18:34:18Z DEBUG m3u_filter::utils::request_utils] Request headers {"accept-language": "de", "user-agent": "VLC/3.0.20 LibVLC/3.0.20", "range": "bytes=0-", "accept": "*/*"}
[2025-01-04T18:44:12Z DEBUG m3u_filter::api::xtream_api] Streaming stream request from http://myXtream.url/series/myUser/myPass/1753625.mkv
[2025-01-04T18:44:12Z DEBUG m3u_filter::api::api_utils] Try to open stream http://myXtream.url/series/myUser/myPass/1753625.mkv

Example stream / codec tested:

Can we reopen the issue if necessary or is there a solution for this by now? Is it perhaps possible to test the behavior using various freely available sources (e.g. m3u file)?

[euzu]

Yes we can reopen this issue. I will try to figure out why it is not working anymore. I know it worked.

[euzu]

@pletexier and @jojo141185 i have pushed changes to the branch reconnect_stream

which includes following changes for reverse proxy mode

• stream reconnect and buffering
• Seeking

It would be nice if you can test it

[jojo141185]

@euzu Thank you euzu! After a short test, unfortunately nothing has changed for me with the latest adjustments. For example, when I try to jump to a certain point in the video, the stream always starts again from the beginning. Used VLC for testing.

is it currently possible to add this m3u with different free video files for testing?

sources:
  - inputs:
    - type: m3u
      enabled: true
      url: 'https://files.catbox.moe/ach5l9.m3u'
      persist: ./playlist_{}.m3u

[euzu]

I have done some tests and live tv is working with all clients, but vod is working only on some clients. I will try to figure out the reason.

[euzu]

@jojo141185 i have oushed some changes to the reconnect_stream branch.

I have tested now with different iptv players, streaming and seeking works.

I have tested with VLC, vlc plays the stream but seeking is not working, i cant figure out why.

[jojo141185]

@euzu, I briefly tested your new approach with VLC. The behavior is better now - at least you can jump to a certain point in the video without the stream starting directly from the beginning. However, the further I jump to the end of the video, the longer it takes for playback to continue from that point. It seems that the proxy retrieves the entire stream sequentially from the beginning to the desired position instead of retrieving the data directly at the desired offset. The linear buffering of the entire stream can be easily recognized if you jump to the end of the video and observe the data rate (e.g. via nethogs)

Maybe we could try a simpler approach (without buffering) first. With the simple copy implementation, as implemented here in iptv-proxy, seeking and jumping to different places in the video worked quickly and without problems for me.

[euzu]

@jojo141185 the seeking works with range headers. each time you go forward or backward the client sends a new request with range. m3u filter forwards this request.

[euzu]

@jojo141185 the implementation is in src/api/model/buffered_stream.rs. You can see there how it is implemented. improvment ideas are welcome.

[euzu]

@jojo141185 i have pushed some changes because some clients do not work if you dont send 206 for partial content.

I have tested now seeking with mobile phone, tv, docker android on linux, hypnotix on linux. It is working.

VLC has some problems, i get

[00007b448c048f00] main decoder error: Timestamp conversion failed for 43627001: no reference clock
[00007b448c048f00] main decoder error: Could not convert timestamp 0 for FFmpeg
[00007b448c048f00] main decoder error: Timestamp conversion failed for 55097001: no reference clock

And stops the seeking. I dont know why this happens.

[jojo141185]

@euzu Thank you for trying again! The behavior on my side is identical to the last attempt I have looked at the error messages in VLC. The following errors don't seem to be a problem, I also get them when I connect directly or use iptv-proxy, where seeking works flawlessly and fast.

main error: Timestamp conversion failed for 4543001: no reference clock
main error: Could not convert timestamp 0 for FFmpeg

In conjunction with m3u-filter, however, I get an additional error when starting the stream, which may be the cause of the problem:

mkv error: cannot find any cluster or chapter, damaged file ?
....

This error does not show up when I connect directly or via iptv-proxy!

After seeking I get the following output in the debug log of m3u-filter:

[2025-01-11T16:19:49Z DEBUG m3u_filter::api::xtream_api] Streaming stream request from http://***/movie/***/1760331.mkv
[2025-01-11T16:19:49Z DEBUG m3u_filter::api::model::buffered_stream] Stream requested with headers: [(“accept”, “*/*”), (“range”, “bytes=938828118-”), (“host”, “192.168.2.10:8901”), (“user-agent”, “VLC/3.0.20 LibVLC/3.0.20”), (“accept-language”, “en”)]
[2025-01-11T16:19:50Z DEBUG m3u_filter::api::model::buffered_stream] Opening stream http://***/movie/***/1760331.mkv with status 206, headers [("content-type", "video/x-matroska"), ("content-length", "5009878879"), ("connection", "keep-alive"), ("accept-ranges", "0-5948706997"), ("content-range", "bytes 938828118-5948706996/5948706997"), ("vary", "accept-encoding"), ("date", "Sat, 11 Jan 2025 16:19:50 +0000")]
[2025-01-11T16:19:50Z DEBUG m3u_filter::api::model::buffered_stream] Client has disconnected from stream http://***/movie/***/1760331.mkv
[2025-01-11T16:19:51Z DEBUG m3u_filter::api::model::buffered_stream] Streaming stopped and no reconnect  for http://***/movie/***/1760331.mkv

Also the message “Client has disconnected from stream” although the player is still connected seems strange.

[euzu]

@jojo141185 The client initiates a new request for each seek operation. This can involve opening a new connection or reusing the existing connection if Connection: keep-alive is supported between the client and server.

When the connection is closed, the client calculates the byte position for the new seek and sends a range request to the server.

Yes, every seek operation results in a new request.

[euzu]

@jojo141185 how do you use vlc for xt api ? or m3u playlist, when i enter the url it plays the first stream, i cant choose any channel? I have tested it with the https://files.catbox.moe/ach5l9.m3u playlist and seeking works. But i cant find a source which has chapters like in your case.

[jojo141185]

@euzu You can open the playlist in VLC and see the different links from the m3u file in the playlist window:

1. Open VLC Media Player.
2. Click View in the menu bar.
3. Select Playlist (or press Ctrl + L)

The last video should have chapters. But seeking is working with these files included in the test m3u, even if the links run via the m3u-filter reverse proxy. There seems to be a difference with files / connection coming from my XT provider. I don't know how to work out what the problem is in this case :-/

[euzu]

@jojo141185 i have tested with vlc and your public video list, i could seek in all videos, i had no problems. Could you name the url which makes problems ?

[jojo141185]

@euzu Tried to set up a test environment to reproduce the problem. I have provided you access data via e-mail. Please try adding it as a source, enable the buffer or retry option and try seeking with vlc as player.

[euzu]

@jojo141185 did you test whit the latest pushes to the reconnect_stream feature branch ?

[jojo141185]

@euzu No, haven't had a chance yet. I'm on a business trip at the moment and won't get around to it until next week.

[euzu]

@jojo141185 seeking is working with the latest release, if you have problems we can start a new issue.

[jojo141185]

@euzu Did you have the opportunity to test with the account I sent you by mail?

[euzu]

I want to test but i dont know if you installed the latest version ? If it is the latest version i can test.

I saw you are running 2.0.10 , can you update to 2.1.0?

http://....:8901/healthcheck

[jojo141185]

@euzu I have updated m3u-filter based on the current master branch. I have buffering and the retry option disabled. The goal would be that you connect via m3u-filter and then activate buffer, test and debug (if it doesn't work)

[euzu]

@jojo141185 you have an email.