search

cabernetwork / cabernet

Cabernet allows control of IPTV streams. Plugins supports DaddyLive, Pluto TV, XUMO, M3U/XMLTV.XML files (SamsungTV, STIRR, DistroTV, Plex TV)
https://cabernetwork.github.io
MIT License
154 stars 22 forks source link

Post Processing #130

Closed cookieisland closed 3 months ago

cookieisland commented 6 months ago

Dan Schmidt also noticed this problem and posted on the tvheadend.org forum with the following comment:

Has anybody else found that their recent recording need to be transcoded else Kodi will stop playing whenever you attempt to fast forward or resume the video? I did not used to have this issue, the ts files used to play just fine in Kodi. My ts files from OTA work just fine.

I have also noticed this fo for the last days/weeks when playing back cabernet/tvheadend recordings on Kodi. We now have to watch all cabernet/tvheadend shows without any PAUSE or FF. I thought it was only Pluto recordings but I just played back a DaddyLive recording and had the same problem. Prior to noticing it on DaddyLive I had been trying to fix this on Pluto by checking/changings some Pluto/cabernet setttings. I have PTS/DTS resync on and also tried to adjust EPG Start Time and End Time to no avail.

Dan mentions transcoding helps. I plan to look into that or potentially could try a postprocessing step to proactively transcode the entire recording after the recording is done.

Like Dan, my OTA recordings via tvheadend/hdhomerun work fine.

purplescorpion1 commented 6 months ago

I don't use kodi but I have no issues pausing the recordings or fast-forwarding the recording on daddylive recorded progs

I use ffmpeg as my stream type

Sounds like a kodi issue or change the stream type

As a workaround for existing recordings just put them through handbrake and re-encode them https://handbrake.fr/

rocky4546 commented 6 months ago

Most of the issues are provider caused, you will need to prove it is a Cabernet issue and not a provider issue.

I ran some tests on the "The Asylum" channel. Cabernet is working correctly and providing the correct stream to TVH. All filters are working correctly. So far, I see no issues with Cabernet.

cookieisland commented 6 months ago

I use docker so I retrieved my log by using the following command: docker logs cabernet >/tmp/cabernet.log 2>&1

cabernet.log

When I Iook at the log, I see a few things

  1. I got an exception at around "2024-01-16 02:28:58" while DaddyLive channel 832 is playing "Escape to the Country"
  2. I am getting "Multiple HTTP Errors" messages when recording some Daddylive channels and also on some EPG updates. I see them on DaddyLive channel 832 (CBC CA), Daddylive 696 (Comet) and Daddylive 356 (BBC One UK). When this happens sometimes I seem to miss multiple segments. Any recommendations on how to mitigate or are these channels just not reliable? The program is viewable as long as I do not hit Pause or FF.
  3. When recording the "Amityville Haunting" on pluto "The Asylum" channel the filter seems to detect commercials and filter them which is good. However, I do get problems when I use Kodi to playback this show between 11.5 to 12 minutes in. At that point if I hit Pause or FF the show quits and bring me to the previous Kodi menu and I cannot get Kodi to resume it where I left off. I have to start from the beginning. Since the show started at"2024-01-17 17:44:59" I think I cannot just add about 11.5-12 minutes to that to find the problem area in the log because a commercial was filtered out. 11.5-12 minutes plus the first commercial might have put the problem near the 2nd commercial which was at "2024-01-17 18:02:00"

I have a question though. When a commercial is filtered it seems the "Connection dropped by end device" happens. Is this normal? Take a look at my log at timestamp "2024-01-17 18:52:05" to see this. Does everything look ok? During this time the tuner seemed to switch from 1165 to 3165.

Thanks

rocky4546 commented 6 months ago

Daddylive is a totally different animal and we are addressing Pluto. For pluto, if you get a connection dropped on live playback, That happens because the stupid PVRHTS plugin for Kodi has a hard coded 10 second timeout and will request a reset/drop connection and restart to TVH. TVH then tells Cabernet to drop the connection and does a new subscribe. If the reset time is short, Cabernet will think it is the same connection anyway and will send the stream to the new port without stopping the stream. It will lose a packet or two in the process.

You can try the keep-alive flag, which works well when recording with tvh, but I recall the pvrhts will only work with active video streams.

The exception is from the new httpx library using the new H2 HTTP protocol. Have not caught all the possible, so added h2.exceptions.StreamClosedError to list of exceptions to catch. According to info, it says that daddylive wanted to send something after the connection had been requested closed by daddylive. So, it is a breach in protocol causing the exception.

cookieisland commented 6 months ago

Thanks!

The Pluto Amityville stuff in the log was a recording that was requested in tvheadend via Kodi. I don't think Kodi was doing a live play of Amityville but I will check with my wife if she had both the recording and was watching via Kodi live as well.

I will try the keep-alive flag.

Sorry about Daddylive. I thought we were addressing both becuase I mentioned in the original post that both Pluto and DaddyLive was having the Pause/FF problem for this issue. Therefore I included a discussion of the DaddyLive stuff in my previous post with my log.

rocky4546 commented 6 months ago

For TVH info, it too has a hard-coded 10 second or so timeout to start receiving a video stream. The keep-alive does not work for the initial startup. Once the startup is done, then TVH uses a configuration parameter for the timeout and the keep-alive works fine. I think it is stupid and they should always use the config timeout, but that is me. To set the timeout, go to the Stream tab in TVH and select pass or htsp. Those are the ones I use for DVR and live. Check the Data timeout value. I have it set to 300, but you can set it to whatever you want. Basically, if this timeout happens after startup, then TVH will send a reset to Cabernet, if the "Restart on error" is set and TVH will start a new file, if recording.

As you can imagine, there might be an issue, if you start the stream when the filtered data is streaming. Then the 10 second hard-coded timeout will be in effect and bad things happen.

cookieisland commented 6 months ago

Thank you very much!

I had previously modified the setting for watching live TV via modifying the "htsp" stream profile. For "htsp" my "Data timeout" was set to 0 (infinite) and "Restart on Error" was off to avoid the situation you describe when watching live TV.

However I had not modified the settings for DVR by adjusting the "pass" stream profile which might explain some or all of my recording issues. I have now set "Data timeout" to 300 and "Restart on Error" to off for "pass" and will see if that helps.

Do you think this will help with all issues including the "Multiple HTTP Errors" message and dropped segments.

If I continue to get Pause/FF problems I will look into putting the postprocessing step in to run the finished recording though a complete end to end ffmpeg/transcoding to smooth things as well.

cookieisland commented 6 months ago

Morning update after setting Data Timeout to 300 and disabling Restart on Error for the 'pass' stream profile

This morning two shows of "Escape to the Country" recorded on DaddyLive channel 832 (CBC CA). One at 2am and one at 10am. I didn't look at the system until about 10:50am and at that time I noticed there was an alarm on the 10am recording in tvheaded's dvr->upcoming/current recording and it was not recording. The 2am recording did record but when I played it back via kodi I got the Pause/FF problem 33:55 into the playback.

I looked at the logs and the 2am recording had a couple of warnings at "2024-01-19 02:23:27" stating:

2024-01-19 02:23:27,118-WARNING:__init__ INVALID m3u format: #EXTM3U missing https://01-24.webhd.ru/ddh2/cdn/premium832/chunks.m3u8
2024-01-19 02:23:32,145-WARNING:__init__ INVALID m3u format: #EXTM3U missing https://01-24.webhd.ru/ddh2/cdn/premium832/chunks.m3u8

cabernet2.log

The 10am recording got some "WARNING:init INVALID m3u format" messages right away when the recording started and ultimately no segments were passed from cabernet to tvheadend until I started Kodi at 10:55 and tuned to the same channel live. It started up for me live and then I stopped playback. Then I looked at tvheadend and the recording had then started and by 11am when it quit it had recorded only the last 5 minutes of the show. When I look at the log once I started the live viewing and subsequently quit the live viewing cabernet kept sending segments to tvheadend for the DVR recording until 11am.

I then looked further back in the log and I see that these "WARNING:init INVALID m3u format" messages have been going on for some time and happened with various DaddyLive channels (691, 672, 678, 680, 671, 354, 688, 674, and 832). I then briefly tried each of these channels playing them live from tvheadend and VLC.

Do you have any recommendations for me? Do you think this a provider problem, Cabernet problem, or some other problem?

Thanks!

rocky4546 commented 6 months ago

I see no issues with Cabernet

cookieisland commented 6 months ago

Ok. Thanks for checking it out and thank you for the work you do on Cabernet.

rocky4546 commented 6 months ago

Just an FYI. I use to go to the daddylive website and see if they can have it run. Many times I find the same issues there as Cabernet. If it is intermittent, that is harder to see. I have also seen the stream change resolution on the fly (VLC can see it). The logs indicate that DL is doing that even though we request a specific resolution. If you want to see DL chat, I have that URL to get around the popups. I have at times requested a channel be reset and that helped. As you are aware, Cabernet is dependent on the quality of the stream. Although I find Pluto and XUMO to be stable, DL is not. December seem to be more stable than January, but that is the way it goes. If you get a m3u failed error over and over (one is not an issue), then the channel needs to be reset by DL. http://daddylivehd.chatango.com/

cookieisland commented 6 months ago

Thank you rocky4546.

I will check out the DL chat link

DL definitely seems to have issues. However they have some channels/programs my wife and I like so I am continueing to see if there is somehting I can do to 'fix' the recordings. I don't mind of some parts of the recording end up being missing and a few seconds gets skipped here and there. I just want to see if I can fix the PAUSE/SKIP/FF issue that makes the entire playback stop.

What I found to be interesting is VLC seems to play the recordings without any problems. But when playing in Kodi I get the PAUSE/SKIP problems.

BTW: I have my postprocessing system working. My first try was to simply apply ffmpeg to the recording with the same options you use in cabernet to fix pts/dts. Unfortunately I still have issues with Kodi and PAUSE/SKIP although there seems to be fewer issues. I am now looking into doing a complete transcode although that takes much longer/more cpu/time.

cookieisland commented 6 months ago

UPDATE: VLC plays the entire video but I had the sound muted on my PC so I didn't notice that the sound quit at some point on VLC. It looks like where the sound goes wonky on VLC is the same point where the Kodi player completely quits video (and of course audio) and goes back to the previous menu.

I took the video and played it directly on Kodi and the video played all the way though even with PAUSE/SKIP. However the audio quit at the same place as it did with Kodi playing the video via the Tvheadend recording.

Strange.

cookieisland commented 5 months ago

As I have been working on this I noticed a couple of exceptions in the log.

One was at 2024-01-20 10:30:20 - looks like an attempt to flush a closed file

The other was was at 2024-01-25 10:55:18 - looks like another HTTP issue after multiple failed HTTP calls - maybe another httpx library issue to catch?

cabernet.log

rocky4546 commented 5 months ago

First error is during termination. It probably terminated the process anyway, but I added a catch for it.

Second error is one that I am still trying to figure out. This is when it runs the HTTP 2.0 protocol and a protocol error occurs. I did add a RemoteProtocolError catch, but that did not catch it, as seen by your log. Looks like httpcore is not handling the error that occurred within its thread and throwing a KeyError, instead. It really should throw the RemoteProtocolError out to the calling program. I will also add the KeyError, but will need to add better text for the cause. I will call it a Protocol Error. So far it occurred on your logs for h2.exceptions.StreamClosedError and httpcore.RemoteProtocolError. Both are caused by HTTP 2.0 protocol issues.

rocky4546 commented 5 months ago

Reviewed streamlink and it used requests library. HTTPX is not doing as well as streamlink, so plan to move back to requests. httpx is throwing exceptions and dev are not working on fixes. RC01 has cabernet using requests. It also has creating a new session for each request for daddylive. I have the parallel downloads currently default to 4, but will change to 1 in next RC. It should now perform the same as streamlink, except you can adjust the http session parms.

cookieisland commented 5 months ago

I am getting better results now that I have a tvheadend postprocess that runs the final recording through ffmpeg to fix pts/dts issues. It is not perfect but it is a lot better than only having pts/dts resync in cabernet for daddylive. I am not sure why but maybe when segments get missed or large timeouts happened the PTS/DTS still gets messed up even with cabernet running it though ffmpeg. I am still on 0.9.14.03 because I was wanting to look more closely at the new docker implementation (I use encryption so I want to be careful that everything is cool before I move my live implementation over). Do you recommend I wait for RC02 or go for RC01?

rocky4546 commented 5 months ago

Not sure why running it through twice is better than running it through once, but I have noticed ffmpeg does not really fix the dts/pts issue. My understanding is the only way to get ffmpeg to fix it is to separate the audio tracks from the video tracks and then merge them back together. I am aware of the ATSC format and that is NOT needed, but ffmpeg does not totally fix the issue.

As for encryption, there is no plugins that use encryption, so it should be fine. Encryption is used to encrypt passwords and other strings in the config.ini file for protection. Encrypted string will begin with ENC... If we were to add a zap2it plugin, that would probably include passwords and then would use the keys.

As for what version to use, I am working on a number of upgrades. For docker I have a list, but will be included later in the RC count. They include:

So, basically patching within docker is disabled with the new version of Cabernet until I get things updated. Also, there is a chicken and egg issue when the latest version of Cabernet requires the latest version of the plugins, so they both need to be upgraded together.

cookieisland commented 5 months ago

I find running it through ffmpeg via the postprocessing improves things but does not fix everything especially if a lot of segments are missing due to DaddyLive timing out. However if a 'managable' number of segments are missing then the recording becomes usable and FF/Pause/etc usually work.

I save the recording prior to replacing it with the one I run through ffmpeg so I can compare the before and after recordings. I have found the following by comparing them:

  1. The recording files are definitely different (ie the one initially saved by tvh/cab vs the one after postprocessing).
  2. When I play both via VLC the one created by tvh/cab often has lots of problems often making it unusable. Sometimes VLC thinks the recordng is only a couple of minutes long or it quits after those few minutes or after FF/etc. However the one that has been run through the postprocess has the correct recording length corrected and doesn't error out with FF, etc (most of the time).
  3. When I play both recordings via Kodi the tvh/cab one often has a LOT of issues. Touching FF/pause/etc will often cause the recording to stop and you have to start again from the beginning (you can not resume). When playing the postprocessed one this is cleaned up (most of the time).

Note (this is not a cabernet issue): An interesting thing is VLC shows the correct recording length when playing the postprocessed recording. However Kodi always shows the length of the recording according to the EPG. It turns out this is how Kodi and the tvh plugin for Kodi were designed to work. SOme people on forums have complained about this. I find it kind of stupid because if you try to fast forward to 'close to the end' of a show it is hard becuase you don't know where the end of the show is. The show may say it is 1 hour long but in reality it might only be 45 mins long.

etofi commented 4 months ago

Can you please post the ffmpeg postprocessing call. I have the same problems and would like to try it out.

cookieisland commented 4 months ago

I have a few scripts. One for the tvh Post-processor command. One for the tvh Post-remove command. One to run daily from cron to clean things up that was missed by Post-remove script

The scripts also includes calling comskip in some instance(s) and cleaning up comskip backup files after tvh removes a recording. Please don't ask about how to configure comskip as I am still experimenting.

tvh_files.zip

etofi commented 4 months ago

Thanks

stale[bot] commented 3 months ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.