Project

General

Profile

Bug #2229

Unicable/EN50494 - TVH disturbs other devices/tuners

Added by Michael - about 10 years ago. Updated about 10 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
Configuration
Target version:
-
Start date:
2014-08-14
Due date:
% Done:

0%

Estimated time:
Found in version:
git - master - commit 5a621b2ff0ae0ac110b6d0df9b4a21e0498abccc
Affected Versions:

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

tvheadend_3.5.248~ge0d07fa.trace.log.zip (17.2 KB) tvheadend_3.5.248~ge0d07fa.trace.log.zip Michael -, 2014-08-15 18:38
tvheadend_3.9.1296~g1dc009a.trace_tvsnosignal.log.zip (88.1 KB) tvheadend_3.9.1296~g1dc009a.trace_tvsnosignal.log.zip Michael -, 2014-08-15 18:38
tvheadend_3.5.248~ge0d07fa.trace.log (46 KB) tvheadend_3.5.248~ge0d07fa.trace.log Michael -, 2014-08-17 17:11
tvheaend_3.9.1309~g91f3b2c.trace.log (93.1 KB) tvheaend_3.9.1309~g91f3b2c.trace.log Michael -, 2014-08-17 17:11
tvheadend_3.9.1352~ge5b83a6-dirty.log (231 KB) tvheadend_3.9.1352~ge5b83a6-dirty.log Michael -, 2014-08-26 19:44
2tuners-tune_tvheadend_3.5.1878~gcaebd9e_amd64_inusasha_amd64.log.zip (21.4 KB) 2tuners-tune_tvheadend_3.5.1878~gcaebd9e_amd64_inusasha_amd64.log.zip Michael -, 2014-09-02 22:42
idlescan_eppgrab_tvheadend_3.5.1878~gcaebd9e_amd64_inusasha_amd64.log.zip (71.2 KB) idlescan_eppgrab_tvheadend_3.5.1878~gcaebd9e_amd64_inusasha_amd64.log.zip Michael -, 2014-09-02 22:42
inital_scan_tvheadend_3.5.1878~gcaebd9e_amd64.log.zip (74 KB) inital_scan_tvheadend_3.5.1878~gcaebd9e_amd64.log.zip Michael -, 2014-09-02 22:42
settings_scanresult.txt (895 Bytes) settings_scanresult.txt Michael -, 2014-09-02 22:42
service_mapper_tvheadend_3.5.1878~gcaebd9e_amd64_inusasha.log.zip (799 KB) service_mapper_tvheadend_3.5.1878~gcaebd9e_amd64_inusasha.log.zip Michael -, 2014-09-02 22:42

History

#1

Updated by Michael - about 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

#2

Updated by Alfred Zastrow about 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ändert

It seems like a driver / hardware issue.
.........................

#3

Updated by Jaroslav Kysela about 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' ?

#5

Updated by Jaroslav Kysela about 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..

#7

Updated by Michael - about 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 ?!

#8

Updated by Sascha Kuehndel about 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

#9

Updated by Michael - about 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

#10

Updated by Sascha Kuehndel about 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.

#11

Updated by Sascha Kuehndel about 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 :))

#13

Updated by Michael - about 10 years ago

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

#14

Updated by Sascha Kuehndel about 10 years ago

Thanks Micheal,

PR is on the way.

#15

Updated by Sascha Kuehndel about 10 years ago

Can Close
Fixed with PR473

#16

Updated by Jaroslav Kysela about 10 years ago

  • Status changed from Need feedback to Fixed

Also available in: Atom PDF