Bug #2229
closed
Unicable/EN50494 - TVH disturbs other devices/tuners
Added by Michael - over 10 years ago. Updated over 10 years ago.
0%
Description
When TVH is running no other tuners (in my case 2 Samsung TV's ) on the same unicable-matrix port are able to tune (showing -> no signal), when I stop TVH the Samsung TVs work again.
Unicable Matrix: TechniRouter 5/2x4
SCR 0 (1218) = Samsung TV
SCR 1 (1400) = TVH (dvbsky s952)
SCR 2 (1516) = TVH (dvbsky s952)
SCR 3 (1632) = Samsung TV
I went back to Seife's Build (3.5.248~ge0d07fa - https://github.com/seife/tvheadend) which works fine with all 4 tuners active the same time.
Files
Updated by Michael - over 10 years ago
Unicable Matrix: TechniRouter 5/2x4
SCR 0 (1284) = Samsung TV
SCR 1 (1400) = TVH (dvbsky s952)
SCR 2 (1516) = TVH (dvbsky s952)
SCR 3 (1632) = Samsung TV
Updated by Alfred Zastrow over 10 years ago
Maybe this is the same cause as in Bug #2194, but it was tagged as "invalid"...
........................
Von Jaroslav Kysela vor 1 Tag aktualisiert
Status wurde von New zu Invalid geändertIt seems like a driver / hardware issue.
.........................
Updated by Jaroslav Kysela over 10 years ago
- Status changed from New to Need feedback
Could you attach/point to the trace logs from the current code and the working code with trace enabled? Trace subsystems: '-all,+linuxdvb,+diseqc' ?
Updated by Michael - over 10 years ago
- File tvheadend_3.5.248~ge0d07fa.trace.log.zip tvheadend_3.5.248~ge0d07fa.trace.log.zip added
- File tvheadend_3.9.1296~g1dc009a.trace_tvsnosignal.log.zip tvheadend_3.9.1296~g1dc009a.trace_tvsnosignal.log.zip added
Attached the traces, hope it helps :)
Updated by Jaroslav Kysela over 10 years ago
Please, use only one (same) channel or service (without the mux scan / epg) in the progress.. Ideally with full tvh run (start - tune one channel - end). Disable mux scan, disable initial mux scan, disable EPG scan before. It's difficult to compare tuning logs for thousands requests... Thanks. But from the first glance, I don't see any major differences..
Updated by Michael - over 10 years ago
- File tvheadend_3.5.248~ge0d07fa.trace.log tvheadend_3.5.248~ge0d07fa.trace.log added
- File tvheaend_3.9.1309~g91f3b2c.trace.log tvheaend_3.9.1309~g91f3b2c.trace.log added
2nd try :-|
Updated by Michael - over 10 years ago
just an assumption:
tvheaend_3.9.1309~g91f3b2c.log
line 74 - 79
2014-08-17 15:53:49.315 [ TRACE]:diseqc: set voltage 18V 2014-08-17 15:53:49.346 [ TRACE]:diseqc: sending diseqc (len 5) E0 10 5A 49 D1 2014-08-17 15:53:49.478 [ TRACE]:diseqc: set voltage 13V 2014-08-17 15:53:49.494 [ TRACE]:diseqc: set voltage 18V 2014-08-17 15:53:49.532 [ DEBUG]:linuxdvb: Montage DS3103/TS2022 : DVB-S #1 - starting 11493H in Astra19.2E 2014-08-17 15:53:49.532 [ TRACE]:linuxdvb: Montage DS3103/TS2022 : DVB-S #1 - tuning
There the Voltage gets raised to 18V followed by the diseqc and then is set back to 13V which is ok, but before the tune the voltage is raised again to 18V and not set back, which could cause the problems with the other tuners - at least if i unsterstood that part of EN50494 right. Or is there just no log message of the voltage reduction ?!
Updated by Sascha Kuehndel over 10 years ago
@Michael Lob
I have an idea, where the problem is.
Can you try https://github.com/InuSasha/tvheadend/tree/fixes/en50494_voltage
It is a dirty hack, that breaks non-unicable DVB-S.
But when it works, we can make the fix.
Thanks,
Sascha
Updated by Michael - over 10 years ago
Hi Sascha,
I tried your "dirty hack" and it looks much better during a normal tune operation
tvheadend_3.9.1352~ge5b83a6-dirty.log 2014-08-26 19:02:54.547 [ TRACE]:linuxdvb: S2CMD 01 => 0 2014-08-26 19:02:54.548 [ TRACE]:diseqc: set voltage 18V 2014-08-26 19:02:54.580 [ TRACE]:diseqc: sending diseqc (len 5) E0 10 5A 4D 8D 2014-08-26 19:02:54.714 [ TRACE]:diseqc: set voltage 13V 2014-08-26 19:02:54.752 [ DEBUG]:linuxdvb: Montage DS3103/TS2022 : DVB-S #1 - starting 12070.5H in Astra 19.2E 2014-08-26 19:02:54.752 [ TRACE]:linuxdvb: Montage DS3103/TS2022 : DVB-S #1 - tuning 2014-08-26 19:02:54.752 [ TRACE]:linuxdvb: tuner Montage DS3103/TS2022 : DVB-S #1 tunning to DVBS pos 19.2E freq 12070500 H sym 27500000 fec 3/4 mod QPSK roff 35 (freq 1517500)
I disabled scanning and EPG completely, otherwise the TV's got disturbed again and showed "No Signal". Also during the initial scan and mux discovery the TVs wasn't able to tune.
Channel/EPG
|- EPG Grabber
|- Over-the-Air-Grabbers: all disabled
DVB Inputs:
|- TV adapters:
|- Over-the-air EPG: disabled
|- Networks
|- Network Discovery: disabled
|- Skip Inital Scan: enabled
|- Idle Scan Muxes: disabled
Regards
Michael
Updated by Sascha Kuehndel over 10 years ago
Thanks for the hint and testing :)
Ok, it's maybe a step forward. But the disturbing of other reciever is bad...
Where is the deference between the old 3.4 patch and the this one???? rip out my hair
When you found an other difference, please tell.
Regards
Sascha
PS: next time, add "en50494" to trace/debug list, please.
Updated by Sascha Kuehndel over 10 years ago
Hi Michael,
can you test the branch again, please.
I took an another look into the standard, and found a bug. And i found an other position for tuning in code.
So i hope the problems will gone.
Happy Testing,
Sascha
PS: is still dirty hack (with extra potion dirt, now :))
Updated by Sascha Kuehndel over 10 years ago
Now i have checked in a clean version.
https://github.com/InuSasha/tvheadend/tree/fixes/bug2229-en50494
Updated by Michael - over 10 years ago
- File 2tuners-tune_tvheadend_3.5.1878~gcaebd9e_amd64_inusasha_amd64.log.zip 2tuners-tune_tvheadend_3.5.1878~gcaebd9e_amd64_inusasha_amd64.log.zip added
- File idlescan_eppgrab_tvheadend_3.5.1878~gcaebd9e_amd64_inusasha_amd64.log.zip idlescan_eppgrab_tvheadend_3.5.1878~gcaebd9e_amd64_inusasha_amd64.log.zip added
- File inital_scan_tvheadend_3.5.1878~gcaebd9e_amd64.log.zip inital_scan_tvheadend_3.5.1878~gcaebd9e_amd64.log.zip added
- File service_mapper_tvheadend_3.5.1878~gcaebd9e_amd64_inusasha.log.zip service_mapper_tvheadend_3.5.1878~gcaebd9e_amd64_inusasha.log.zip added
- File settings_scanresult.txt settings_scanresult.txt added
Hi Sascha,
Finally I found a time to try your branch.
The disruption of the TV's seems to be gone, at least i wasn't able to reproduce it so easy like the last time. Also during the inital scan and the service mapping (just used 1 tvh tuner) the TVs worked like they should.
I had some traces running during all the time - maybe they are useful somehow, if not just ignore them.
The only what looks a bit strange to me at the moment are the only 733 mapped channels (from 1809 services), but this maybe is an other issue - who knows :P
Anyway - lets see if the TVs keep working :)
Thanks for your work so far.
- Michael
Updated by Jaroslav Kysela over 10 years ago
- Status changed from Need feedback to Fixed