Tvheadend

G Kazaroth wrote:

Issue with DistroTV is the channel ids used contain all kinds of illegal characters (like a space). I will add some fix into the internal_proxy, but when I tested it, it did work fine with the stream_type set to m3u8redirect.

Edit: I have added code in RC05 for m3u plugin to replace invalid characters in the channel id with '_'. This should help the m3u files with invalid characters work. This only affects the stream type internal_proxy.

I tried changing to m3u8redirect and it did not appear to make any difference. These are the settings I am currently trying to use:

[m3u_distrotv]
label = M3U DistroTV
channel-m3u_file = https://raw.githubusercontent.com/DeltaSr95/DistroTV/master/distrotv.m3u
epg-suffix = D
enabled = True
channel-import_groups = True
player-enable_pts_filter = True
player-enable_pts_resync = True
epg-xmltv_file = https://github.com/DeltaSr95/DistroTV/blob/master/distrotv.xml.gz?raw=true
player-stream_type = m3u8redirect
player-decode_url = True
player-enable_url_filter = True

EDIT: Also tried going back to internal_proxy, still no luck.

I will note that although I upgraded Cabernet, the home screen still says the version is Version: 0.9.6.0-RC04. I don't know why because it definitely upgraded, I did it twice the usual way and then went and got the zip file from the repository and installed from that and still it says it's on RC04. EDIT: Now its on Version: 0.9.6.0-RC06 and I am sorry to report that it's still having the same problems.

I am playing it directly from TVH mux list to VLC and it works perfectly. Even with your settings (most of which have nothing to do with m3u8redirect.)

G Kazaroth wrote:

I am playing it directly from TVH mux list to VLC and it works perfectly. Even with your settings (most of which have nothing to do with m3u8redirect.)

The problem I am having is that TVH will not scan the channels in in the first place. Out of 89 muxes that I enabled, only 33 will successfully scan in, and those do play in VLC. The rest just fail for some unknown reason, and TVH does not create a service for them.

My automatic IPTV settings are these:

Enabled: ✔

Network name: M3U-DistroTV
Create bouquet:

Maximum # input streams: 5 (set to 1 for initial scan)
Maximum bandwidth (Kbps): 0
URL: http://localhost:6077/m3u/distrotv/channels.m3u
Channel numbers from: 0
Accept zero value for TSID: ✔

Provider network name:
Network ID (limit scanning): 0
Ignore provider's channel numbers:

SAT>IP source number: 0
Character set: (none specified)
Use A/V library:

Scan after creation: ✔

Priority: 1
Streaming priority: 1
Maximum timeout (seconds): 45
Icon base URL:
Content character set: (none specified)
Re-fetch period (mins): 1440

(Everything in the "Expert Settings" is left at the defaults).

I have tried several different variations of the settings for the instance in Cabernet, and none of them seem to make any difference. If I could just get TVH to scan in the channels in the first place I suspect they would work, though I can't be certain of that because I can't get TVH to scan the channels in. The fact that it does scan 33 out of the list indicates to me that there is some difference in the channels on that list. Also a channel that will not scan it still wont scan no matter how many times you try it. I even tried deleting all the DistroTV muxes so that they would be reloaded using the upgraded version of Cabernet and that made no difference. So at this point I'm almost ready to throw in the towel and just disable all the channels that Tvheadend can't seem to scan in. I'm glad it works for you, I just wish I knew why!

EDIT: Well it just gets weirder, I tried again this evening and a few more scanned in, tried again once more and now all but 8 of the channels have scanned in, but those 8 refuse to scan (an example is channel 32, "24 Hour Free Movies"). Might be they are down, might be a connectivity issue, who knows. But today's update definitely seems to have helped the situation, so thanks!

I got all but 2 with internalproxy. Had over 8 with m3u8redirect. One had the wrong url with a 404 error and the other was failing on distrotv as well. The distrotv data for the m3u file is coming from
https://tv.jsrdn.com/tv_v5/getfeed.php
if you are interested.

I have cabernet configured for SamsungTV, Plex and USTVGO. The channels.m3u has all the expected channels. I can see them all from the channels page in cabernet. The xmltv.xml file only includes the Samsung/Plex channels...nothing for USTVGO. Thus, in my tvheadend setup, all the channels are shown in the channels tab but the EPG doesn't include any of the USTVGO channels.

What might be impacting the contents of the xmltv.xml file?

Sounds like you may not have "XMLTV Enabled" checked/turned on in the EPG section of your "USTVGO Instance"

Also you may want to run "Refresh USTVGO EPG" in the scheduled tasks section.

G Kazaroth wrote:

I got all but 2 with internalproxy. Had over 8 with m3u8redirect. One had the wrong url with a 404 error and the other was failing on distrotv as well. The distrotv data for the m3u file is coming from
https://tv.jsrdn.com/tv_v5/getfeed.php
if you are interested.

Well today all the remaining ones scanned in but one and that one is indicated as geo-locked so maybe it's rejecting my IP address. Anyway just wanted to say thanks again for all your work on Cabernet.

C Island wrote:

Sounds like you may not have "XMLTV Enabled" checked/turned on in the EPG section of your "USTVGO Instance"

Also you may want to run "Refresh USTVGO EPG" in the scheduled tasks section.

good catch. I'd forgotten that. I get the EPG data now. Thanks.

There is still an issue with getting guide data, and it seems if even one provider has a problem with their XML file it poisons the entire XML file. The problem today is Stirr. I created an instance using the links at https://i.mjh.nz/Stirr/ and it works fine except that the http://localhost:6077/m3u/stirr/xmltv.xml file produced by Cabernet ends like this (I used "R" as the channel suffix):

        <channel id="externallinearfeed-12-04-2019-185615218-12-04-2019">
        <display-name>102R Stingray Flashback 70s</display-name>
        <display-name>102R Stingray Flashback 70s</display-name>
        <display-name>102R</display-name>
        <display-name>Stingray Flashback 70s</display-name>
        <display-name>Stingray Flashback 70s</display-name>
    </channel>
HTTP/1.0 501 Not Implemented
Server: BaseHTTP/0.6 Python/3.7.3
Date: Wed, 03 Nov 2021 21:09:48 GMT
Content-type: text/html

<html>
        <head></head>
        <body>
            <h2>501 - Server Error</h2>
        </body>
    </html>

It appears to be doing the channels section just fine, but when it gets to the program listings something bad happens, and this goes into the combined XML file at http://localhost:6077/m3u/xmltv.xml and that in turn causes Tvheadend to reject the whole thing as bad. If I disable the EPG in the Stirr instance then I get a good file, but without the Stirr listings. If I go directly to https://i.mjh.nz/Stirr/all.xml I see the original XML file which looks okay, but of course it does not have the channel number suffixes and it does have all the icon links that I don't want.

DistroTV is another one, if I go to http://localhost:6077/m3u/distrotv/xmltv.xml I only get the channel tags at the beginning and that is it. The link for the XML on that one is a bit strange, it is https://github.com/DeltaSr95/DistroTV/blob/master/distrotv.xml.gz?raw=true but Cabernet must be getting it and extracting it because it is able to create the channel section, it just stops when it gets to where it should copy the program listings. I have a feeling the above to issues are related somehow because they both involve the program listings not being created. My suspicion is that there is some character or something in the original XML files that Cabernet doesn't like, but doesn't handle gracefully. I hope it isn't a difficult thing to fix but it would be really nice to have guide data for all the channels, at least where guide data is available!

I was not checking the Stirr m3u file during tests. Thanks for catching it. I have made a change I think will fix issue in RC07. Just upgrade to RC08 and do a EPG refresh on M3U Stirr.

G Kazaroth wrote:

I was not checking the Stirr m3u file during tests. Thanks for catching it. I have made a change I think will fix issue in RC07. Just upgrade to RC08 and do a EPG refresh on M3U Stirr.

Yep, that fixed it, thanks! As for DistroTV I found out that I had to set the XMLTV File Type to gzip rather than autodetect, then it works. This is probably because the downloaded filename actually ends in .gz?raw=true which I assume Cabernet doesn't automatically recognize as a .gzip file. After changing that, it looks like I now have guide data for all channels, or at least all those that have data available.

Yes, you would need to set the file type, if the url does not end in a file name. In your case, it ended in a query_string. You could have used a direct url and it would have detected the file type:
https://raw.githubusercontent.com/DeltaSr95/DistroTV/master/distrotv.xml.gz
But either way, it does work.

I haven't used or updated Cabernet since Locast died (Is there a way to find out what Cabernet version I'm running from the web interface?).

I'm thinking about giving some of the other plugins a try.

What would be the best way to update Cabernet at this point?

Thanks

The version should appear in Settings > Internal > Main. If your version is very old, then you can find it in the file [install location]/lib/common/utils.py

If you only have the Locast plugin, then the best method is to start from scratch and install the latest version from
https://github.com/cabernetwork/cabernet/releases
What I did was remove all files in the install folder and put the new files into it. (like the lib, plugins, and top level files) The services should still work since it calls the tvh_main.py file at the top level.
Once you have the new version, upgrades become easy.

Thanks, I'm on v0.8.8g. I'll try removing the files from the install folder.

I attempted to download cabernet-0.9.6.0-RC08.exe but Windows Security identified it as containing Trojan:Win32/Spursint.F!cl and aborted the download.

I understand sometimes .exe files can falsely be identified as a threat but I thought I'd ask just to be sure before I tell Windows Security it is OK.

I've attached a screenshot.

I check with Bitdefender and Malwarebytes. Neither indicated a virus.
I believe it is a Microsoft Defender alert and has indicated some kind of cloud-based protection issue and not a virus itself. (Basically, it does not like where the file came from) Based on what I read online, it could also be caused by the exe is not signed and is not a known installer that Microsoft knows about.

Did you download it and try to install from your Desktop? Noting you have info in the log indicating it is complaining of where the exe came from. I suspect MS Windows may still track where the file originated even if on the Desktop.

The only thing in the installer remotely possible is the request for ffmpeg to be installed from a remote site; otherwise, I cannot imagine anything that caused it. We are using the actual ffmpeg site for that installer, so that would not be an issue.

Never mind about the cabernet-0.9.6.0-RC08.exe. I thought it was a self extracting compressed file, I didn't realize it was a Windows setup file.

To refresh your memory, I'm running TVH 4.2.8 on a CoreELEC box. I installed the Python 3.9.4 modules necessary to get Tvheadend-Locast running on my system.

I downloaded the "Source code (zip)" file that was underneath the "cabernet-0.9.6.0-RC08.exe" file and extracted the files.
I deleted all the files in the install folder (named "tvheadend-locast") and copied the extracted files there.
I created a data folder inside the installation folder and created a config.ini file inside the data folder.
I edited the config.ini and added the following lines:

[plutotv_default]
label = PlutoTV Instance

I launched the app by running the command "python3 tvh_main.py" and got the following results:

CoreELEC:~ # cd tvheadend-locast
CoreELEC:~/tvheadend-locast # python3 tvh_main.py
Traceback (most recent call last):
File "/storage/tvheadend-locast/tvh_main.py", line 10, in <module>
from lib import main
File "/storage/tvheadend-locast/lib/main.py", line 29, in <module>
import lib.clients.web_tuner as web_tuner
File "/storage/tvheadend-locast/lib/clients/web_tuner.py", line 34, in <module >
from lib.streams.internal_proxy import InternalProxy
File "/storage/tvheadend-locast/lib/streams/internal_proxy.py", line 30, in <m odule>
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
ModuleNotFoundError: No module named 'cryptography'

When I go to http://ipaddress:6077/ I get "This site can’t be reached". I used to be able to bring up Cabernet.

Anything I obviously did wrong? (I tried rebooting my CoreELEC box with same results)

So Pluto, as well as some other providers, encrypt the streams, unlike Locast. The cryptography module is now required to decrypt the streams.

Not sure why 6077 is not up. It normally comes up no matter what...

Well, I thought I got the cryptography module installed correctly but now I get the following and then it just hangs:

CoreELEC:~ # cd tvheadend-locast
CoreELEC:~/tvheadend-locast # python3 tvh_main.py
2021-11-04 15:18:52,815-WARNING:main #########################################
2021-11-04 15:18:52,816-WARNING:main MIT License, Copyright (C) 2021 ROCKY4546

That would be normal when the logging is set to WARNING (default). Next step is to connect to the website at 6077 and finish configuring the plugin.

I still get "This site can’t be reached" when I try to connect to the website at 6077.
But I can access TVHeadend at 9981.

If you haven't rebooted CoreElec I recomend you do that. The port might be allocated/locked by the old tvheadend-locast instance or the previous tvh_main.py that failed. A reboot should clean up any ports that were allocated and locked.

I did a hard reboot where I shut down and pulled the power cord. Still can't get to Cabernet at 6077.

You can also check on the box to see if the port is working (therefore its a firewall or network issue). If you have telnet, try

telnet localhost 6077
GET / HTTP/1.0

Press ENTER twice after the GET line and you should get a response from cabernet. If you have wget, then try

wget http://localhost:6077/

and see if you get a response. In both cases, a 302 response should be returned.