Project

General

Profile

Bug #5907

SATIP services hidden and unplayable

Added by Jamie E. over 4 years ago. Updated over 4 years ago.

Status:
Invalid
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
2020-05-29
Due date:
% Done:

0%

Estimated time:
Found in version:
HTS Tvheadend 4.3-1880~g2af3b9e2e
Affected Versions:

Description

I have 2 tvheadend machines setup on raspberry pi 3b's to output via satip, one is version 4.3-1880~g2af3b9e2e (raspian 9 stretch), and the other is 4.2.8-34~g24a2f59e9 (raspian 10 buster)
These are then both pulled into a docker version of tvheadend running 4.3-1880~g2af3b9e2e as satip adapters

All services play and are visible on the main machines. When mapped on the satip receiver (docker version), all services are mapped but 80% of them are always under "parent disabled"
All muxes and networks (only 1) are enabled, and i can randomly get one service from a mux shown but the rest hidden

All hidden services can not be played at all but channels are mapped automatically for them all via the bouquet.
I can also not launch the hidden services via the channel list if automatically or manually mapped

I have attached 2 screenshots, all visible channels show details like the appropriate screenshot, all hidden show as per the hidden screenshot.
If i re-scan the muxes, the services shown as hidden change each time

It does not matter which satip device i use for this, they both have the same behaviour (disabling one to limit and test each)


Files

hidden.PNG (7.65 KB) hidden.PNG Jamie E., 2020-05-29 12:55
visible.PNG (15.6 KB) visible.PNG Jamie E., 2020-05-29 12:55

History

#1

Updated by Jamie E. over 4 years ago

As a follow up, the tvheadend log when trying to play a hidden service via VLC is as follows

2020-05-29 16:27:29.454 http: 192.168.0.230: using ticket 1e2553e63cfb3dc015d530eb5a69b60f35fc3eff for /stream/service/7b6c4011f918257e2a20b8630aedec31
2020-05-29 16:27:31.454 subscription: 0002: No input source available for subscription "HTTP" to service "DVB-T Network/514MHz/BBC ONE W Mid" in mux "514MHz in DVB-T Network"
2020-05-29 16:27:31.454 webui: Couldn't start streaming /stream/service/7b6c4011f918257e2a20b8630aedec31?ticket=1e2553e63cfb3dc015d530eb5a69b60f35fc3eff, No service enabled
2020-05-29 16:27:31.454 subscription: 0002: "HTTP" unsubscribing, hostname="192.168.0.230", client="VLC/3.0.10 LibVLC/3.0.10"
2020-05-29 16:27:31.494 http: 192.168.0.230: using ticket 1e2553e63cfb3dc015d530eb5a69b60f35fc3eff for /stream/service/7b6c4011f918257e2a20b8630aedec31
2020-05-29 16:27:33.494 subscription: 0003: No input source available for subscription "HTTP" to service "DVB-T Network/514MHz/BBC ONE W Mid" in mux "514MHz in DVB-T Network"
2020-05-29 16:27:33.494 webui: Couldn't start streaming /stream/service/7b6c4011f918257e2a20b8630aedec31?ticket=1e2553e63cfb3dc015d530eb5a69b60f35fc3eff, No service enabled
2020-05-29 16:27:33.494 subscription: 0003: "HTTP" unsubscribing, hostname="192.168.0.230", client="VLC/3.0.10 LibVLC/3.0.10"

#2

Updated by Pablo R. over 4 years ago

I also have seen that. The problem is that those services does not take stream parameters during scan (PCR,H24/MPEG/audio...), only PMT is seen.

#3

Updated by Pablo R. over 4 years ago

For me this problem also happen for DVB-T phisycal adapters. It is not exclusive of satip.

#4

Updated by Jamie E. over 4 years ago

That seems to be correct. As a follow on to this I have found that if I delete the services that are hidden and rescan, then keep repeating this, eventually the services do come through but it can take 10 or 15 attempts minimum

The satip server I am using for testing this part is the stable release

Is it possible this could be down to low signal?

#5

Updated by Jamie E. over 4 years ago

I can now confirm this is not due to low signal. Previously some of the channels had signal strength of -81dbm, they are all no lower then -39dmb and the issue still persists

#6

Updated by Jamie E. over 4 years ago

Sorry to keep posting but i am just ruling things out now

Both the satip receiver (85) and the raspberry pi (81) that was running the stable release are running version 4.3-1885~ge1031ce5d
To rule out any issues of multiple receivers, i have only enabled this one satip source (81) on the main receiver (85) install

The main tuner (81) tunes 102 services mapped and visible, with another 43 hidden that should not be
The satip client (85) tunes and again only receives between 5 and 36 services as visible, with the remaining hidden

All 3 instances (including the other receiver (80)) show the same 145 services total but with varying numbers mapped so it seems to affect everything as Pablo R. saw and not just satip although the satip receiver seems to consistently map a much lower amount than the main devices

The lowest signal strength i saw was -45dbm during tuning which from what i can find out is perfectly acceptable. I have however noticed that some of the services do have PMT and PCR mapped but obviously with no mpeg streams still

#7

Updated by Jamie E. over 4 years ago

Ok, last follow up to this for a while

I removed tvheadend from both transmitter device (80 and 81) and instead ran minisatip on them

Connected them both to the satip receiver running tvheadend (85) and i now have 99 services scanned and working flawlessly from both devices. This is consistent no matter how many times i delete and re-scan all services so for now, i'm going to stick with this

#8

Updated by g siviero over 4 years ago

I have a similar problem with Mux scanning. I still don't know what's causing it (good services "hidden" under parent disabled), but I found that setting the option "Maximum PIDs" to a lower value in the SAT>IP adapter before the scan usually solves my problem.

#9

Updated by Flole Systems over 4 years ago

You are most likely subscribing to more PIDs than your driver/server supports.

#10

Updated by Flole Systems over 4 years ago

  • Status changed from New to Invalid

Also available in: Atom PDF