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
176 stars 23 forks source link

Tuners being left active when no longer in use #14

Closed itprotj closed 1 year ago

itprotj commented 2 years ago

When tuning to different channels, Cabernet shows that a tuner is active for the channel I am tuned to (or tvh is scanning). However, the tuner is never marked inactive and keeps spawning new python.exe processes and they don't end by themselves either.

rocky4546 commented 2 years ago

Thanks for entering an issue. I would like to get some info from the log. While in DEBUG mode, if you can make a clean start so no tuners are running. Then go into TVH MUX and turn one of the channels from IDLE to PEND. This should cause Cabernet to run a tuner scan on just one channel. If we can get the tuner to stick, post the log info on the rows when the mux starts to scan through the end. Also, do not have the browser watching the home page. It just clogs up the log.

itprotj commented 2 years ago

Hey matey,

Yep so tuner stayed active even after tvh had finished scan. Here is the log. It started to get cluttered with the logs of the browser as I went in after a minute or so to check if the tuner was still in use and rebooted cabernet after that.

cabernetlog.txt

rocky4546 commented 2 years ago

Thanks for the log.

This is good information. I need to look into why the added item on the forked process queue is not being pulled off by Cabernet after 16:09:43. So, the tuner process was still running and sending data to Cabernet. Cabernet was not picking up the data. Will get back to you.

rocky4546 commented 2 years ago

What does not make sense is Cabernet served the stream to TVH from 8:41 to 9:43. It looks like you have the timeout set to 60 seconds in TVH, but you said you set it to 30 seconds. Please clarify. Also, if it is set to 60 seconds, then Cabernet should have received a HTTP connection termination notice from TVH, but it is not listed. It just hangs waiting for TVH to finish receiving the stream indicating TVH did not terminate the connection. My first guess is something is wrong with TVH. Can you try using VLC with the same URL http://ip:5004/M3U/watch/USBC600018CF and see if we get the same results?

itprotj commented 2 years ago

Hey Rocky

I've done some further testing with the advice you gave and apologies for wasting your time on this. It appears this is a TVH issue. Streaming directly from cabernet is working fine and disconnects the tuner properly when the stream is stopped. TVH on the other hand does not.

I take it the next step would be to raise this with the TVH community unless you feel it would be beneficial continuing here?

Thanks again

itprotj commented 2 years ago

These are the TVH Debug logs for when I ran the cabernet stream from tvheadend. It says it has stopped the stream however looking at cabernet the tuner is still very much active.

2022-06-03 14:41:29.165 [ INFO]:http: 192.168.100.17: using ticket bb7af086b1a04538bd018628ec981636cc2d8889 for /stream/mux/85592b9cc71b70c158edbd6fee0fbcc0 2022-06-03 14:41:29.165 [ DEBUG]:mpegts: channels.m3u - CHIVE TV in Internet IPTV Streams - add raw service 2022-06-03 14:41:29.165 [ DEBUG]:service: 2: channels.m3u - CHIVE TV in Internet IPTV Streams si 0x7f1fa81854f0 weight 0 prio 11 error 0 (OK) 2022-06-03 14:41:29.165 [ DEBUG]:service: 1: channels.m3u - CHIVE TV in Internet IPTV Streams si 0x7f1fa82279b0 weight 0 prio 11 error 0 (OK) 2022-06-03 14:41:29.165 [ INFO]:mpegts: channels.m3u - CHIVE TV in Internet IPTV Streams - tuning on IPTV #1 2022-06-03 14:41:29.171 [ DEBUG]:mpegts: channels.m3u - CHIVE TV in Internet IPTV Streams - open PID 0000 (0) [20/0x7f1fa821d8b0] 2022-06-03 14:41:29.171 [ DEBUG]:mpegts: channels.m3u - CHIVE TV in Internet IPTV Streams - open PID 0001 (1) [16/0x7f1fa8182370] 2022-06-03 14:41:29.171 [ DEBUG]:mpegts: channels.m3u - CHIVE TV in Internet IPTV Streams - open PID 0010 (16) [20/0x7f1fa817cf00] 2022-06-03 14:41:29.171 [ DEBUG]:mpegts: channels.m3u - CHIVE TV in Internet IPTV Streams - open PID 0011 (17) [20/0x7f1fa82f1170] 2022-06-03 14:41:29.171 [ DEBUG]:mpegts: channels.m3u - CHIVE TV in Internet IPTV Streams - open PID 0011 (17) [16/0x7f1fa8195320] 2022-06-03 14:41:29.171 [ DEBUG]:mpegts: channels.m3u - CHIVE TV in Internet IPTV Streams - started 2022-06-03 14:41:29.171 [ DEBUG]:mpegts: channels.m3u - CHIVE TV in Internet IPTV Streams - open PID fullmux subscription [0003/0x7f1fa134f810] 2022-06-03 14:41:29.171 [ INFO]:subscription: 00BA: "HTTP" subscribing to mux "channels.m3u - CHIVE TV", weight: 10, adapter: "IPTV #1", network: "Internet IPTV Streams", service: "Raw PID Subscription", hostname="192.168.100.17", client="VLC/3.0.16 LibVLC/3.0.16" 2022-06-03 14:41:31.177 [ DEBUG]:service: channels.m3u - CHIVE TV in Internet IPTV Streams: Status changed to [CA check] 2022-06-03 14:41:32.844 [ DEBUG]:service: channels.m3u - CHIVE TV in Internet IPTV Streams: Status changed to [Demuxed packets] [CA check] 2022-06-03 14:41:32.844 [ DEBUG]:service: channels.m3u - CHIVE TV in Internet IPTV Streams: Status changed to [Demuxed packets] [Reassembled packets] [CA check] 2022-06-03 14:41:32.845 [ DEBUG]:webui: Start streaming /stream/mux/85592b9cc71b70c158edbd6fee0fbcc0?ticket=bb7af086b1a04538bd018628ec981636cc2d8889 2022-06-03 14:41:32.845 [ DEBUG]:tbl-base: sdt: onid FF01 (65281) tsid 0001 (1) 2022-06-03 14:41:32.845 [ DEBUG]:tbl-base: sdt: mux channels.m3u - CHIVE TV in Internet IPTV Streams 2022-06-03 14:41:32.845 [ DEBUG]:tbl-base: sdt: sid 0001 (1) running 4 free_ca 0 2022-06-03 14:41:32.845 [ DEBUG]:tbl-base: pat: 0x7fffb94b0500: tsid 0001 (1) 2022-06-03 14:41:32.845 [ DEBUG]:tbl-base: pat: sid 0001 (1) on pid 1000 (4096) 2022-06-03 14:41:32.845 [ DEBUG]:tbl-base: pat: completed pid 0 table 00000000 / 00000000 2022-06-03 14:41:32.850 [ DEBUG]:tbl-base: sdt: completed pid 17 table 00000040 / 000000f8 2022-06-03 14:41:55.054 [ INFO]:subscription: 00BA: "HTTP" unsubscribing, hostname="192.168.100.17", client="VLC/3.0.16 LibVLC/3.0.16" 2022-06-03 14:41:55.054 [ DEBUG]:mpegts: channels.m3u - CHIVE TV in Internet IPTV Streams - close PID fullmux subscription [0003/0x7f1fa134f810] 2022-06-03 14:41:55.054 [ DEBUG]:mpegts: channels.m3u - CHIVE TV in Internet IPTV Streams - stopping mux 2022-06-03 14:41:55.054 [ DEBUG]:mpegts: channels.m3u - CHIVE TV in Internet IPTV Streams - close PID 0000 (0) [20/0x7f1fa821d8b0] 2022-06-03 14:41:55.054 [ DEBUG]:mpegts: channels.m3u - CHIVE TV in Internet IPTV Streams - close PID 0001 (1) [16/0x7f1fa8182370] 2022-06-03 14:41:55.054 [ DEBUG]:mpegts: channels.m3u - CHIVE TV in Internet IPTV Streams - close PID 0010 (16) [20/0x7f1fa817cf00] 2022-06-03 14:41:55.054 [ DEBUG]:mpegts: channels.m3u - CHIVE TV in Internet IPTV Streams - close PID 0011 (17) [16/0x7f1fa8195320] 2022-06-03 14:41:55.054 [ DEBUG]:mpegts: channels.m3u - CHIVE TV in Internet IPTV Streams - close PID 0011 (17) [20/0x7f1fa82f1170]

rocky4546 commented 2 years ago

I thought about giving you a small change file to increase logging, but we may be able to determine if it is a TVH bug. If you run the test and cabernet process/tuner hangs, then restart TVH. If the tuner clears after a short, then the issue is a TVH bug. Although strange, if this is the case, you can try going to 4.2 or 4.3 based on your current version. Also, I recommend trying jellyfin as a complete media server as well as DVR.

There is only one way I know to hang the cabernet processes. It is for the client to keep the HTTP connection open while NOT accepting any data from it. This will cause the queues to fill and basically plug up cabernet. I really cannot do much about this case. TVH as well as others squelch the data while the provider can provide the stream at a much faster rate. If the rates are different, cabernet has to buffer the data. If you restart TVH, then the connections will drop and cabernet should indicate the client closed the connection and do a cleanup on the tuner.

itprotj commented 2 years ago

I thought about giving you a small change file to increase logging, but we may be able to determine if it is a TVH bug. If you run the test and cabernet process/tuner hangs, then restart TVH. If the tuner clears after a short, then the issue is a TVH bug. Although strange, if this is the case, you can try going to 4.2 or 4.3 based on your current version. Also, I recommend trying jellyfin as a complete media server as well as DVR.

There is only one way I know to hang the cabernet processes. It is for the client to keep the HTTP connection open while NOT accepting any data from it. This will cause the queues to fill and basically plug up cabernet. I really cannot do much about this case. TVH as well as others squelch the data while the provider can provide the stream at a much faster rate. If the rates are different, cabernet has to buffer the data. If you restart TVH, then the connections will drop and cabernet should indicate the client closed the connection and do a cleanup on the tuner.

Just to confuse us both even more, I restarted tvh with tuners being "active" in cabernet and the tuners are still in cabernet as active. How long are they meant to hang in cabernet for if tvh rebooted for instance?

Will have a look into Jellyfin.. I take it it is a lot more stable then TVH I would hope.. It seems the stability of tvh is very sketchy... a very comprehensive bit of software but a steep learning curve. All the live tv I use comes in on IPTV streams apart from some free to air stuff on HDHomeRun Tuners, as long as jellyfin can handle that it is worth a shot.

Thanks

rocky4546 commented 1 year ago

I have found a case where the tuner was not disabled when a provider was not responding. This has been fixed and should be available in the next release. 0.9.9

rocky4546 commented 1 year ago

Fix test successfully 0.9.9.7. With the additional state information on the main page, it will let you know what the state of every tuner is. I did have it lock up the queues and it still found a way to shutdown the tuner and cleanup the processes.