Tvheadend

On your exception, the key error indicates that you have plugin: M3U; instance: custom2; in your database, but you have removed it from your config.ini file.

As you mentioned, to clean up the database, you need to remove the m3u/custom2 instance. If you go to Data Mgmt/Delete Instance, you should find the M3U:custom2 instance in the list. Remove that and you should be good.

G Kazaroth wrote:

On your exception, the key error indicates that you have plugin: M3U; instance: custom2; in your database, but you have removed it from your config.ini file.

As you mentioned, to clean up the database, you need to remove the m3u/custom2 instance. If you go to Data Mgmt/Delete Instance, you should find the M3U:custom2 instance in the list. Remove that and you should be good.

Yeah, I had figured that out, I had just thought that maybe Cabernet could handle that situation a little more gracefully, or at least print some kind of warning on the home screen or something. I would guess that most users don't delete instances often, so when you do it is easy to forget that you also need to go in and remove the data for that instance. All I knew initially was that I wasn't getting guide data and I had no idea why until I checked the log (which was not my first course of action because usually I never read log files, and also I always forget which log file Cabernet puts its entries in).

Not a huge deal, the problem is fixed. I guess I don't know if you consider Cabernet finished and have moved on to other things, or if you still feel like polishing it a bit more. I know at one point you had talked about putting up a web page for it but then we never heard any more about that. One thing I have been thinking for a while now is that it would be good to have some kind of wiki where you could have a page corresponding to each settings page, and also for each streaming service (including the m3u ones) with the suggested settings for each one. I always feel like I am flying blind whenever I have to adjust settings, even though many of them do have mouseover tooltips. The settings that I always feel the most uncertain about in are the provider instance tabs. For example, there is the "Enable PTS/DTS Resync" setting. What I have discovered is if you enable it on streams that don't require it, they may not be playable (the stream will never start playing). But the opposite is also true; if you don't enable it on a stream that does require it, it will either not play at all or you might get video but no audio. And there is just no way to tell ahead of time which streams require it and which don't. I wound up having to create two lists and instances for individual feeds, one for the channels that don't need PTS/DTS Resync and another for those that do. If I add a channel I try it in one list first and if it doesn't work there, then in the other.

I totally disabled Xumo because I never could figure out good settings for that; any time I tried to record something it would either record the wrong show or it would record for just a few minutes and quit, and since most of their channels are also present in other services and their guide data was often minimal or incomplete, I just decided that Xumo wasn't worth the hassle.

Please don't get the idea that I am trying to load you down with a bunch of projects if you are ready to move on to something else. I only mention this stuff in case you happen to be looking for something to do over the winter months, but also because these notes might be helpful to me or someone else at some point. I just know it's been over a month since the last update was released and I didn't know if you had moved on to other projects or if you've just been occupied with other things over the holidays or what. In any case, no pressure, for the most part Cabernet is working quite well now, and that's the main thing.

Also (year end reflection here) I know it must have been pretty demoralizing when Locast abruptly shut down (and then those other few unofficial Locast-like streams did the same), I know that was your original purpose for the program and I think we were all shocked by how quickly Locast just folded after that terrible decision by a judge that was probably born when horses and buggies and telegrams were still a thing. Locast had always led us to believe that they had the law on their side and that they would fight any adverse legal decision vigorously, but then when they had one bad ruling against them they folded like a tent in a hurricane, without even making any kind of appeal. My guess is they decided that if they could not strongly encourage people to donate by interrupting programming, the service would never be financially viable. But still I don't think anyone expected them to just up and shut everything down that quickly. I also think if they hadn't relied on that donation nag everyone would have been a lot more sympathetic toward them and might even have donated to a legal defense fund for them, but who knows.

G Kazaroth wrote:

Cabernet does chunk the xmltv.xml output in instance/day chunks, so it should send something to the client fairly often, but if it somehow hangs due to I/O buffering or whatever, wget will terminate the connection after 60 seconds of dead space. Per the man page on wget:

"if, at any point in the download, no data is received for more than the specified number of seconds, reading fails and the download is restarted."

You can make a decision on what timeout you want to use. It was just another possible reason you could be having issues.

I changed -T to 120 but the problem is still the same. The problem occurs consistently every 2 days sometimes successfully running one more time after 48 hours has expired. It seems like a token is expiring or something like that.

Sterling Rorden wrote:

G Kazaroth wrote:

Cabernet does chunk the xmltv.xml output in instance/day chunks, so it should send something to the client fairly often, but if it somehow hangs due to I/O buffering or whatever, wget will terminate the connection after 60 seconds of dead space. Per the man page on wget:

"if, at any point in the download, no data is received for more than the specified number of seconds, reading fails and the download is restarted."

You can make a decision on what timeout you want to use. It was just another possible reason you could be having issues.

I changed -T to 120 but the problem is still the same. The problem occurs consistently every 2 days sometimes sometimes successfully running one more time after 48 hours has expired. It seems like a token is expiring or something like that.

Some more information:

If I SSH into the box and issue a Telnet ping to 6077 I get a connection refused.
If I ping 9981 on the same box (Tvheadend) I get a response that the connection is open.
If I try to access Cabernet via the web access I get a connection refused response from my browser.
I can access the Tvheadend web interface on the same machine.
However, I can tell from the Cabernet log that Cabernet is still active.

Is there a way to automatically restart Cabernet on a schedule? I could give that a try.

On USTVGO, I am getting a 404 error for the url https://ustvgo.tv/data.php
Looking into the issue.

They have a new API and web site. It's going to take a little time to get it updated, so in the meantime, I recommend disabling the plugin.

On Reddit someone had posted this:

Just use ustvgo_to_m3u by Benmoose39. Not an “Addon” so it needs an initial configuration but works great with Kodi. When USTVGO changed something yesterday and it stopped working it was fixed same day. Before someone asks for help, he has a discord Channel

I assume they are talking about this: https://github.com/benmoose39/ustvgo_to_m3u

So if you get stuck, I don't know if you would be able to see what changes he made to his program in the last few days (not real familiar with how Github works) but if you can then you might be able to determine what needs to be changed in Cabernet. Hope this helps.

I think I have it working. They shutdown the backend api so they can control which channels require their VPN to stream. This way they get a monthly subscription for pay to view channels. If USTVGO requires a VPN that you do not have, Cabernet will remove those channels from the list. To see the list of channels with and without VPN, check out.

https://github.com/benmoose39/ustvgo_to_m3u/blob/main/ustvgo_channel_info.txt

Those with VPN at the end will require a VPN to stream.

It may come out today, if testing gets done.

Thanks, it seems to be working fine on the three or four channels I tested it on. And it does appear to be removing the channels that require a VPN (I don't have one) from Cabernet's channel list.

But I saw another issue when I went into Cabernet to do the update - the main page showed a M3U tuner in use that I know was not being used by Tvheadend. This worries me that it may not always be releasing channels when Tvheadend disconnects. Is it possible to set a maximum stream timer that will automatically disconnect a tuner that's been in continuous use for longer than a specified amount of time? For example I'd probably want to set it for six hours because I cannot conceive of a circumstance where a tuner should be in continuous use for that long (that is long enough for two movies back to back on most channels).

I'm aware that I could set up a cron job to do a forced restart of Cabernet in the middle of the night, only reasons I don't like that idea are because first of all it could actually be PVR'ing something at that time, and also Cabernet might be in the middle of some process involving the database during that time (not that I really think that would cause a problem, because I think it would probably start that process over when it comes back up).

If you want to do a restart, you should use the scheduler and not some cronjob that kills processes. The scheduler will cause a clean shutdown and restart, so any database issue would be mitigated.

1. Is the tuner actually running or is the state wrong? If no INFO logging is going on, then the tuner is not really running.
2. Is there more than three python3 tvh_main.py processes running? When no tuners are in use, there should only be 3 processes. If more than 3 are there and no logs show an active tuner, then the process is not terminating properly.
3. Are there any exceptions in the log? This can help to resolve how a tuner is still active while terminated.

So, the next time you see a tuner process still present, take a look and see if you can find any info.
Thanks

Thanks, I will do that. For some reason I had set the log level to DEBUG so just now I set it back to INFO, but I did look as best I could at the INFO entries for the last day and a half and I saw where some tuners had been accessed and streams were played, but nothing at all about the channel that was supposedly in use according to Cabernet's home page. Also I did not see any exceptions, but then again I had it set to DEBUG so there was a LOT of information in there, so just because I didn't see any doesn't guarantee there weren't any such entries.

In any case if I see this happen again I'll try to get the information you requested. I know this happened to me once before but that was quite some time back, maybe even late summer or autumn. So it's not a frequent thing but you never know, it may happen again. Since as far as I can tell, the log seems to indicate that the tuner was not really running and the home page was giving a false indication, I won't schedule a periodic shutdown and restart for now.

Sterling Rorden wrote:

Sterling Rorden wrote:

G Kazaroth wrote:

Cabernet does chunk the xmltv.xml output in instance/day chunks, so it should send something to the client fairly often, but if it somehow hangs due to I/O buffering or whatever, wget will terminate the connection after 60 seconds of dead space. Per the man page on wget:

"if, at any point in the download, no data is received for more than the specified number of seconds, reading fails and the download is restarted."

You can make a decision on what timeout you want to use. It was just another possible reason you could be having issues.

I changed -T to 120 but the problem is still the same. The problem occurs consistently every 2 days sometimes sometimes successfully running one more time after 48 hours has expired. It seems like a token is expiring or something like that.

Some more information:

If I SSH into the box and issue a Telnet ping to 6077 I get a connection refused.
If I ping 9981 on the same box (Tvheadend) I get a response that the connection is open.
If I try to access Cabernet via the web access I get a connection refused response from my browser.
I can access the Tvheadend web interface on the same machine.
However, I can tell from the Cabernet log that Cabernet is still active.

Is there a way to automatically restart Cabernet on a schedule? I could give that a try.

Well, I found a workaround. I didn't realize clicking on the clock icon would allow me to schedule a restart - Duh.
I set a schedule to restart Cabernet every night. I've gone several days now without any problems.

I don't know if you have any interest but there is what I would consider a "Locast Lite" that is expanding into more cities this year:

https://cordcuttingreport.com/2022/01/27/localbtv-ceo-interview/

The bad part is that they only seem to carry a few of the subchannels and, so far at least, none of the major networks. The possibly good part is they are attempting to do this in a 100% legal manner, so there is no chance of getting shut down the way Locast did.

I can't say that I have much interest in any of the channels they currently carry (and they are not in my area yet anyway) but maybe some people would.

I'm guessing you never got anywhere with those PBS channels?

G Kazaroth wrote:

Cabernet for (Cable Network) version 0.9.5 (10/22/2021)
PlutoTV, USTVGO, XUMO, M3U/XMLTV, SamsungTV, Plex¶

Provides a configurable interface from providers to TVHeadend.

• Direct plugin for USTVGO, PlutoTV, XUMO
• M3U Plugin provides channels for: SamsungTVPlus, Plex, Binge, DStv, Foxtel, Kayo, Optus, PBS, Singtel, SkyGo, SkySportsNow, SparkSport, Stirr, and others
• From: https://i.mjh.nz/
• Import your own M3U file

https://github.com/cabernetwork/cabernet/releases
Working on getting a service that will take the PlutoTV or XUMO server stream, clean it and feed it into TVHeadend and other DVRs (Also tested on Emby, JellyFin and Plex). It works on the subscription and free versions. Also it runs on Linux and Windows as a service. Windows has a installer. Once installed, setup is easy with TVHeadend.
1) Setup the automatic IPTV network (recommend new URL is http://[host]:6077/PlutoTV/channels.m3u)

Make sure to set the "Maximum # input streams". PlutoTV is set to a max of 4 and tvheadend uses 2 per tuner during initial screening. Doing a force scan will create the mux and service values. Also, turn View level to Advanced and set the Re-fetch period (mins) to a very large number. TVheadend has a tenancy to cause issues when channels change (Changed Services will not be mapped to channels). The Maximum Timeout is used to wait for a reply during a Forced scan. Recommend keep this low, like 15-20 seconds. Some of the channels may fail, but it is faster than having a high setting and waiting for all channels to scan. Just individually rescan those that failed by setting each mux back to PEND from IDLE.
2) Next you can setup the grabber. I use a URL grabber written in Unix bash and is an extremely small file. It can be found in the github repo at
https://github.com/cabernetwork/cabernet/tree/master/lib/tvheadend/service/Unix called tv_grab_url
Place the grabber file in the same location as the other TVHeadend tv_grab* files, change the permissions to executable and restart TVHeadend. This should allow TVHeadend to pickup the new grabber. While in the grabber list, make sure and disable any OTA grabbers. Stations no longer send this information and will only cause TVHeadend to use a tuner for scanning. Displaying the log window by clicking the three ^ in the bottom right is helpful at this time.

Have the grabber run and populate the EPG data into the EPG Grabber Channels tab. The log should show a quantity of channels were detected.
Pop over to the EPG Grabber tab and disable the OTA grabber cron. Also, update/replace the Internal grabber cron schedule using something like below. The example will pull the TV guide at 6:04am and 5:52pm. Add more if you need. It is recommended to use static cron times.
[...]
3) In the Channel view, select Map all channels.

This will tie the services, EPG and channels together, automatically. After this, re-grab the EPG data. This will populate the EPG tab with shows. For TVH version 4.3, the Number column will auto-populate. For TVH 4.2, you will need to manually add channel numbers.
4) Display the TVGUIDE. This appliance has special features which maps the tvheadend genre, giving colors on tvguides. It also has enhanced guide descriptions and optional additional channel notations if you use many streams. Below is the Kodi tvguide using the pvr.hts plugin.

For Kodi, go to the settings for PVR and turn on the General setting "Use channel numbers from backend".

I'm Sorry if this is not the right place to get help but I can not get anything to work except accessing the web ui, thats it no channels, epg or anything.

just need the ustvgo & m3u plugins to work but nothing populates in cabernet under channel editor at all for any provider

Wow, that was a long reply...
The application is a plugin/instance based app. When first started, all plugins are disabled and no instances are present. Take a look at the github home page for instructions on how to add an instance. Once a instance is added to config.ini, you can restart the app and the instance will appear in the providers settings area (and disabled). You can then configure the instance and plugin, and enable both. Then restart the app to have the instance run.

For USTVGO, we recommend the following settings at this time:
- Enabled: checked
- Enable PTS/DTS Resync: checked
- PTS/DTS Resync Type: ffmpeg
- XMLTV Enabled: checked
- EPG Channel Prefix: (optional) use a number like 1000 to start the channel numbers at 1000 (then use the same trick to m3u instances like 2000, 3000, etc)
(all other check boxes disabled...)

I am pretty sure the rest should be defaults...
The reason for disabling everything is ... we want to have you setup the instance before turning it on. It makes the first scan for channels and EPG much smoother.

Well it is happening again...

G Kazaroth wrote:

If you want to do a restart, you should use the scheduler and not some cronjob that kills processes. The scheduler will cause a clean shutdown and restart, so any database issue would be mitigated.

EDIT: I tried that (AFTER getting the information shown below) and while it appeared to restart Cabernet, something was not right in that I could not successfully stream anything until I restarted the process from the command line.

I am not one to use band-aids to fix an issue, so if there is a tuner showing on the home page, it would be nice to fix it. The issue is, we need more info.

1. Is the tuner actually running or is the state wrong? If no INFO logging is going on, then the tuner is not really running.

There are a whole bunch of INFO entries and new ones are being created as I write this, they all look like this:

Feb  5 14:42:06 systemname locast[27779]: 2022-02-05 14:42:06,156-INFO:web_handler [127.0.0.1] "GET /tunerstatus HTTP/1.1" 200 -
Feb  5 14:42:06 systemname locast[27779]: 2022-02-05 14:42:06,174-INFO:web_handler [127.0.0.1] "GET /api/dashstatus.json HTTP/1.1" 200 -
Feb  5 14:42:09 systemname locast[27779]: 2022-02-05 14:42:09,258-INFO:web_handler [127.0.0.1] "GET /tunerstatus HTTP/1.1" 200 -
Feb  5 14:42:09 systemname locast[27779]: 2022-02-05 14:42:09,283-INFO:web_handler [127.0.0.1] "GET /api/dashstatus.json HTTP/1.1" 200 -
Feb  5 14:42:12 systemname locast[27779]: 2022-02-05 14:42:12,361-INFO:web_handler [127.0.0.1] "GET /tunerstatus HTTP/1.1" 200 -
Feb  5 14:42:12 systemname locast[27779]: 2022-02-05 14:42:12,390-INFO:web_handler [127.0.0.1] "GET /api/dashstatus.json HTTP/1.1" 200 -
Feb  5 14:42:15 systemname locast[27779]: 2022-02-05 14:42:15,488-INFO:web_handler [127.0.0.1] "GET /tunerstatus HTTP/1.1" 200 -
Feb  5 14:42:15 systemname locast[27779]: 2022-02-05 14:42:15,512-INFO:web_handler [127.0.0.1] "GET /api/dashstatus.json HTTP/1.1" 200 -

Also the last time it did stream an actual channel it was a different one than the one that is supposedly active now.

1. Is there more than three python3 tvh_main.py processes running? When no tuners are in use, there should only be 3 processes. If more than 3 are there and no logs show an active tuner, then the process is not terminating properly.

There are four:

27217 ?        Sl     0:08 /usr/bin/python3 /home/hts/cabernet/tvh_main.py -r 1
27779 ?        Ssl   60:11 /usr/bin/python3 /home/hts/cabernet/tvh_main.py -r 1
28145 ?        Sl   276:24 /usr/bin/python3 /home/hts/cabernet/tvh_main.py -r 1
28154 ?        Sl   8284:34 /usr/bin/python3 /home/hts/cabernet/tvh_main.py -r 1

1. Are there any exceptions in the log? This can help to resolve how a tuner is still active while terminated.

None in the last day and a half.

So, the next time you see a tuner process still present, take a look and see if you can find any info.
Thanks

Don't know if this is at all helpful but I hope so.

I guess I needed to be more clear... but that is OK.
The INFO logs you show says you are on the home page. You would need to not be on the home page in order to see if any INFO logs happen from the streaming process and not the webpage refresh...
So, not really what I was hoping to see, but let's see if we can figure this out.

You show 4 processes, so one is stuck. It is the one with the highest process number (28154). The nice part is the log tags some lines with the process ID, so we can see what happened last with that process. Recommend taking the log and filtering to "28154" and see what you get. You should get
"INFO:pts_resync PTS Resync running ffmpeg" showing the process is starting for the new stream
"INFO:internal_proxy Serving 28154 ..." showing that it is running the stream
At the end, the stream will terminate with the log
"INFO:internal_proxy Connection dropped by end device [Errno 32] Broken pipe 28154" or something similar. This should occur within about 60 seconds from the last Serving log entry. I suspect the last entry is missing, but any info after the last Serving associated with process 28145 for about 60 seconds would be great.

Another note, process id 28145 is your tuner/steaming process running on port 5004.

EDIT: 5004 port is 28145, not 27779

Well I had restarted it but now it is doing it again, except now it shows two channels in use (that really aren't in use). So, I closed the tab to Cabernet completely so the web page is not being refreshed. That does stop the stream of output to the log.

Now I see five processes:

 6371 ?        Sl     0:04 /usr/bin/python3 /home/hts/cabernet/tvh_main.py
22546 ?        Sl     0:35 /usr/bin/python3 /home/hts/cabernet/tvh_main.py
30219 ?        Ssl    9:16 /usr/bin/python3 /home/hts/cabernet/tvh_main.py
30299 ?        Sl    42:52 /usr/bin/python3 /home/hts/cabernet/tvh_main.py
30308 ?        Sl   2373:22 /usr/bin/python3 /home/hts/cabernet/tvh_main.py

Neither of those two last process numbers appear in the syslog (even going back five days), however process 30219 does show many entries but that seems to be a general Cabernet task because it shows background tasks and such. And it doesn't appear to be associated with either of the the channels that are stuck (see below).

I'm going to force restart it again and see what happens. Maybe I can actually get something useful if it happens again.

EDIT: Just to add, after restarting it, I brought the m3u list into VLC and tried playing the two channels that the interface showed as being stuck - both played normally and neither left behind an entry in the home page. My SUSPICION of what may have happened was that someone attempted to record from those two channels on Sunday and Monday, but for some reason neither could be streamed at that time. The log from Sunday does show this:

Feb  6 20:58:49 systemname locast[30219]: 2022-02-06 20:58:49,567-INFO:web_handler [xx.xx.xx.xx] "GET /M3U/watch/9522 HTTP/1.1" 200 -
Feb  6 20:58:49 systemname locast[30219]: 2022-02-06 20:58:49,664-NOTICE:plugin_channels M3U: Getting best video stream info for 9522 https://[redacted].m3u8
Feb  6 21:00:48 systemname locast[30219]: 2022-02-06 21:00:48,641-INFO:internal_proxy Connection dropped by end device [Errno 104] Connection reset by peer 22360
Feb  6 21:01:04 systemname locast[30219]: 2022-02-06 21:01:04,360-NOTICE:web_tuner Provider Connection Closed, ch_id=9522
Feb  6 21:01:17 systemname locast[30219]: 2022-02-06 21:01:17,268-INFO:web_handler [xx.xx.xx.xx] "GET /M3U/watch/9522 HTTP/1.1" 200 -
Feb  6 21:01:17 systemname locast[30219]: 2022-02-06 21:01:17,369-NOTICE:plugin_channels M3U: Getting best video stream info for 9522 https://[redacted].m3u8
Feb  6 21:01:19 systemname locast[30219]: 2022-02-06 21:01:19,131-INFO:internal_proxy Serving 22546 https://[redacted].ts (6.006)s (2591584B) ttw:0.19s
Feb  6 21:01:19 systemname locast[30219]: 2022-02-06 21:01:19,349-INFO:internal_proxy Serving 22546 https://[redacted].ts (6.006)s (2791440B) ttw:0.00s
(.....|
Feb  6 21:11:18 systemname locast[30219]: 2022-02-06 21:11:18,151-INFO:internal_proxy Serving 22546 https://[redacted].ts (6.172)s (2856480B) ttw:0.00s

9522 was one of the "stuck" channels. I have no idea why it says "Connection dropped by end device" because Tvheadend attempted (and failed) to record from that channel at that time. It is possible that the user that scheduled the recording saw that it was a rerun or something and stopped it but either way it did not stop gracefully - the last entry shown above appears to be the last one having anything to do with that channel.

I am so confused by all this, not sure what is going on.

Make sure all processes have stopped before restarting Cabernet. It looks like they stopped, but the process time of 2373 seems to say it ran for a while. If a process is disconnected, Cabernet will not know to stop it.

Your log shows some interesting info that may indicate what the issue is. It looks like the channel may be starting and stopping at the same time. This could be associated with changing channels. There could be some kind of race condition that is not covered. I will take a look and see if I can reproduce it.

Edit: I tried reproducing the issue and was unsuccessful. I still believe it is something you do, but not sure what it is. Keep giving information and maybe we can figure this out.

TVHeadend will drop the connection if Cabernet does not start "Serving" the connection within a specified period of time (in your case, it looks like you have it set to 120 seconds), it will disconnect. Seems like a very long time to wait to get a stream. The second time it tried, it was successful. It looks all normal. When a "connection dropped by end device" occurs, the counters for the home page are updated, so that should not be the issue.

I currently have the problem that when recording PlutoTV (Sci-Fi / Star Trek) with Tvheadend I either have no sound at all or after a commercial break the sound is gone.

I have already tried all combinations:

These three I have always left the same

stream_type = internalproxy
Non-VOD Segments to Start = 3
PTS/DTS Resync Type = ffmpeg

I have already tried all combinations:

Enable URL Filtering = on
Enable PTS/DTS Resync = on

Enable URL Filtering = on
Enable PTS/DTS Resync = off

Enable URL Filtering = off
Enable PTS/DTS Resync = on

Does anyone have a working setting that solves my problem?

It is possible that the provider has made changes. I will run some recordings for Star Trek through TVH and see what happens. I record with URL filtering on, PTS/DTS Resync off and Non-VOD Segments set to 1. Also have the start time setup so the recording starts just after the program starts and ends just before the program ends. I will let you know the results.

EDIT: First test is showing some issues. Looking into the issue.

Issue #1: @Shea: Fixed issue when tuner is left on home page. This was caused by the ATSC module and causes 100% CPU usage. Probably causing lots of other issues. Problem solved in 0.9.7.1. Does not fix the audio issue after ads. Working on next fix.

Issue #2: @Trosch: Fixed issue on PlutoTV when it comes back from ads. Issue was 2-fold. One item was related to how chunk messages were being sent to TVH. The other was related to when default ATSC msgs were sent to client. Biggest thing is to make sure your timeout is long enough in TVH. Go to Configuration > Stream > Stream Profiles. Select the profile you are using and check the "Data Timeout". It should either be 0 or large enough to get through the ads without timing out.

G Kazaroth wrote:

It is possible that the provider has made changes. I will run some recordings for Star Trek through TVH and see what happens. I record with URL filtering on, PTS/DTS Resync off and Non-VOD Segments set to 1. Also have the start time setup so the recording starts just after the program starts and ends just before the program ends. I will let you know the results.

EDIT: First test is showing some issues. Looking into the issue.

Thanks for your help

So, today I didn't have any EPG data for PlutoTV and USTVGO but the channels would play. I discovered that my tv_grab_url file had completely disappeared. I put another copy in the same place that the other tv_grab* files are and it seems to be working again.

Anyone else have this happen?

Ich hätte da noch eine Frage. Was ist eigenlich das offizielle Docker Image?
Bisher habe ich nur das hier gedunden https://registry.hub.docker.com/r/eblabs/cabernet
Aber das wurde irgendwie mit dm Update auf 0.9.7.1 nicht aktualisiert

UPDATE:
I found the offical on.

ghcr.io/cabernetwork/cabernet:latest

I think I have both Shea and Trosch issues resolved. Check out 0.9.7.3. More notes are above in the previous reply.

Only issue I still find is a defunc process is still occurring when the m3u8 process does not terminate correctly. Restarting the app seems to clear the process.