Bug #2714
closed
DVB-C over SAT>IP generates a log of fake services
Added by FuN KeY about 10 years ago.
Updated about 10 years ago.
Description
At first I attached my DVB-C tuner (HVR-930c) to TVH using USB. I then connected that tuner to a raspberry and I consume it over SAT>IP (satpi is the SAT>IP server).
When the tuner was directly attached to TVH, everything went fine, but now over SAT>IP a lot a fake services are generated. This is pretty annoying as their number continuously increase, I have to manually remove those.
The ghost channel are added even without active scanning, for example simply tunning to a real channel on the mux 354Mhz add 3 ghost channel on the mux 426Mhz. I saw nothing our of the ordinary in the log.
Files
Describe more the ghost services (are they from the tuned mux?). Also, compile tvh with --enable-trace and provide trace for "--trace pat,sdt,nit,bat" and describe what services are added (names, service IDs etc.).
But thinking more about this.. I would "bet" that it's a satpi issue (the input or output buffers are not flushed correctly, so incorrect mpeg-ts packets are received).
Hi Jaroslav Kysela,
I am the dev of SatPI and I am wondering which buffer you mean? or do you mean maybe waiting on sync bytes?
Can you please explain somehow why you think this is the case?
Regards,
Marc
Marc Postema wrote:
Hi Jaroslav Kysela,
I am the dev of SatPI and I am wondering which buffer you mean? or do you mean maybe waiting on sync bytes?
Can you please explain somehow why you think this is the case?
TVHeadend uses same code-path for mpegts data received from the linuxdvb and SAT>IP client code, so it's probably unlikely that tvheadend add extra services when they are not in the incoming MPEG-TS stream. For SAT>IP when the tuning parameters are changed, tvh used always different UDP ports to make sure that even the network buffering causes issues (late data from the previous tuning).
It seems that after new tune, some packets from previous tuning are received, but tvheadend takes these data as "received from the tuned multiplex". It might screw the logic in tvheadend (parsers for the service info tables). The SAT>IP server must flush all data from previous tuning completely in the driver (for example: tvheadend begins to grab the data from the linuxdvb driver when the tuner is locked, until then - there are no open/read operations for the linuxdvb demux device).
Hi Jaroslav Kysela,
I think you are right (according to FuN KeY tests) it is indeed an buffer issue in SatPI..
Thanks for explaining this to me.
Regards,
Marc
The latest version of satpi fixes the issue, you can close this ticket (I couldn't find how).
Thank you Jaroslav Kysela and Marc for your support!
- Status changed from New to Fixed
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by