Bug #2714
DVB-C over SAT>IP generates a log of fake services
0%
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
History
Updated by
Updated by Jaroslav Kysela over 9 years ago
Updated by 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.).
Updated by Jaroslav Kysela over 9 years ago
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).
Updated by FuN KeY over 9 years ago
Good point. I did forward your input to the satpi dev (https://github.com/Barracuda09/SATPI/issues/20).
I will gather the requested debug data in the upcoming days.
Updated by Marc Postema over 9 years ago
Updated by 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
Updated by Jaroslav Kysela over 9 years ago
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).
Updated by Marc Postema over 9 years ago
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
Updated by FuN KeY over 9 years ago
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!
Updated by 