Posts by Sundtek

Bezüglich Bildstörungen bei DVB-C (sollte es denn Bildstörungen geben), oder gar eine Raspberry PI da hilft oft ein längeres USB Kabel. Zum Teil helfen auch Ringkerne um diverse Kabel.

Wichtig ist wenn es auftritt, die Signalstärke und BER auszulesen damit man mal Anhaltspunkte hat woran es liegen kann und welche Frequenzen überhaupt betroffen sind.

Mir ist eigentlich kein einziger Kunde bekannt der seine Kabelprobleme nicht in den Griff bekommen hat, im Allgemeinen haben eigentlich sehr wenige Probleme.

Bei älteren Installationen hilft es auch die Kabeldose auszutauschen.

Schalte die Logfile des Treibers ein

/etc/sundtek.conf

loglevel=max

Das zeigt mal an ob die Daten die via USB übertragen wurden in Ordnung sind

/var/log/mediasrv.log wäre der Output

Was nicht schaden würde wäre eine Statistik wie der RPI4 zu dem Zeitpunkt getaktet war (wie viel MHz).

Die Frage wäre auch was dort alles via USB dranhängt?

Eventuell auch einfach nur mal /opt/bin/mediaclient --readsignal=0 -d /dev/dvb/adapter0/frontend0 --band universal (adapterX wobei X für den Tuner steht) im Hintergrund mitlaufen lassen.

ERROR: can't open filter handle on '/dev/dvb/adapter1/demux0'

das zieht sich wirklich durch die gesamte Syslog Logfile.

Schalte eventuell mal die Logfile des Treibers ein (denke jetzt aber nicht dass dort ein Problem angezeigt wird).

/etc/sundtek.conf

logfile=max

In der Logfile steht üblicherweise /dev/dvb/adapterX/demux0, eventuell hast Du die Minor ID von den Demuxer Nodes nicht richtig durchgereicht?

läuft das Ganze in einem LXC Container?

Von den anderen Nodes sehe ich eigentlich keine Probleme (frontend0 / dvr0).

Wenn Du mir irgendwie remote Zugriff geben kannst kann ich mir das kurz mal direkt anschauen.

Im Laufe der nächsten Woche wird auch noch unser neuer Streamingserver freigegeben, sprich eher eine aktualisierte Version der vorigen Version, sollte dann auch einfach einzubinden sein.

Quote from MarkusE

Meine sehr alten sundtek USB Sticks hatten noch eine schlechte USB Anbindung, und sind eigentlich nicht mehr zu gebrauchen (sind aber wirklich schon sehr alt).

Meine Sundtek SkyTV Ultimate Dual ist im Produktivbetrieb. Funktioniert oft sehr gut, aber manche Aufnahmen haben dann super viele TS Fehler (mehr als 10000). Muss ich mal genauer analysieren. Ev. ist einer der 2 Tuner defekt.

Verwendest Du die aktuellen Treiber?

/opt/bin/mediaclient --loglevel=max

dann /var/log/mediasrv.log überprüfen, dort wird die Frequenz angegeben wo das Problem sein könnte.

Glaube kaum dass da ein Tuner defekt ist, die sind ziemlich robust.

Der Streamingserver für die Geräte wird in kürze mit SAT>IP erweitert, dann könnt ihr auch damit rumspielen.

Wer's günstig sucht:

https://www.ebay-kleinanzeigen.de/s-anzeige/sundtek-skytv-ultimate-dual-neu/2312441262-175-6687

würde da sofort zugreifen, ein kleiner SAT>IP Server wird in 1-2 Wochen auch freigegeben für die Tuner. Der Stromverbrauch ist minimalst.

Bei den Sundtek Tunern:

/opt/bin/mediaclient -e oder je nach system vielleicht auch nur mediaclient -e zeigt an welche devices vom Treiber bereitgestellt werden.

Kannst du vdr mit valgrind starten?

Die Probleme sehen mir ein bißchen größer aus, und vor allem im Bereich des PAT Filters.

(die ersten beiden IOCTLs wurden entfernt da sie nicht initialisiert ok sind (und mittendrinnen wurden auch einige entfernt um das 10.000 Zeichen limit nicht zu übersteigen):

https://pastebin.com/inurDVwX

==234899== 
==234899== Invalid free() / delete / delete[] / realloc()
==234899==    at 0x483D1CF: operator delete(void*, unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==234899==    by 0x27D171: cListBase::Del(cListObject*, bool) (tools.c:2227)
==234899==    by 0x22B3D6: cPatFilter::SwitchToNextPmtPid() (pat.c:410)
==234899==    by 0x22CBE8: cPatFilter::Process(unsigned short, unsigned char, unsigned char const*, int) (pat.c:479)
==234899==    by 0x244B55: cSectionHandler::Action() (sections.c:211)
==234899==    by 0x26DDE4: cThread::StartThread(cThread*) (thread.c:301)
==234899==    by 0x4B03608: start_thread (pthread_create.c:477)
==234899==    by 0x5153292: clone (clone.S:95)
==234899==  Address 0xee13bc0 is 0 bytes inside a block of size 32 free'd
==234899==    at 0x483D1CF: operator delete(void*, unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==234899==    by 0x27D171: cListBase::Del(cListObject*, bool) (tools.c:2227)
==234899==    by 0x1EDF1E: SetStatus (filter.c:189)
==234899==    by 0x1EDF1E: cFilter::SetStatus(bool) (filter.c:178)
==234899==    by 0x22D21D: cPatFilter::SetStatus(bool) (pat.c:350)
==234899==    by 0x24476A: cSectionHandler::SetStatus(bool) (sections.c:152)
==234899==    by 0x1CC2B8: cDevice::SetChannel(cChannel const*, bool) (device.c:891)
==234899==    by 0x1CC7C5: cDevice::SwitchChannel(cChannel const*, bool) (device.c:809)
==234899==    by 0x1E845B: cEITScanner::Process() (eitscan.c:168)
==234899==    by 0x1AA833: main (vdr.c:1519)
==234899==  Block was alloc'd at
==234899==    at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==234899==    by 0x1EE488: cFilter::Add(unsigned short, unsigned char, unsigned char, bool) (filter.c:218)
==234899==    by 0x22CBE8: cPatFilter::Process(unsigned short, unsigned char, unsigned char const*, int) (pat.c:479)
==234899==    by 0x244B55: cSectionHandler::Action() (sections.c:211)
==234899==    by 0x26DDE4: cThread::StartThread(cThread*) (thread.c:301)
==234899==    by 0x4B03608: start_thread (pthread_create.c:477)
==234899==    by 0x5153292: clone (clone.S:95)
==234899== 
==234899== Invalid read of size 8
==234899==    at 0x22B3DE: Next (tools.h:654)
==234899==    by 0x22B3DE: Next (tools.h:665)
==234899==    by 0x22B3DE: cPatFilter::SwitchToNextPmtPid() (pat.c:411)
==234899==    by 0x22CBE8: cPatFilter::Process(unsigned short, unsigned char, unsigned char const*, int) (pat.c:479)
==234899==    by 0x244B55: cSectionHandler::Action() (sections.c:211)
==234899==    by 0x26DDE4: cThread::StartThread(cThread*) (thread.c:301)
==234899==    by 0x4B03608: start_thread (pthread_create.c:477)
==234899==    by 0x5153292: clone (clone.S:95)
==234899==  Address 0x10 is not stack'd, malloc'd or (recently) free'd
==234899== 
==234899== 
==234899== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==234899==  Access not within mapped region at address 0x10
==234899==    at 0x22B3DE: Next (tools.h:654)
==234899==    by 0x22B3DE: Next (tools.h:665)
==234899==    by 0x22B3DE: cPatFilter::SwitchToNextPmtPid() (pat.c:411)
==234899==    by 0x22CBE8: cPatFilter::Process(unsigned short, unsigned char, unsigned char const*, int) (pat.c:479)
==234899==    by 0x244B55: cSectionHandler::Action() (sections.c:211)
==234899==    by 0x26DDE4: cThread::StartThread(cThread*) (thread.c:301)
==234899==    by 0x4B03608: start_thread (pthread_create.c:477)
==234899==    by 0x5153292: clone (clone.S:95)
==234899==  If you believe this happened as a result of a stack
==234899==  overflow in your program's main thread (unlikely but
==234899==  possible), you can try to increase the size of the
==234899==  main thread stack using the --main-stacksize= flag.
==234899==  The main thread stack size used in this run was 8388608.
==234899== 
==234899== HEAP SUMMARY:
==234899==     in use at exit: 85,790,583 bytes in 1,288,520 blocks
==234899==   total heap usage: 2,467,507 allocs, 1,178,989 frees, 2,204,044,461 bytes allocated
==234899== 
==234899== LEAK SUMMARY:
==234899==    definitely lost: 20,056 bytes in 496 blocks
==234899==    indirectly lost: 448 bytes in 14 blocks
==234899==      possibly lost: 2,240 bytes in 7 blocks
==234899==    still reachable: 85,767,839 bytes in 1,288,003 blocks
==234899==         suppressed: 0 bytes in 0 blocks
==234899== Rerun with --leak-check=full to see details of leaked memory
==234899== 
==234899== Use --track-origins=yes to see where uninitialised values come from
==234899== For lists of detected and suppressed errors, rerun with: -s
==234899== ERROR SUMMARY: 27 errors from 20 contexts (suppressed: 0 from 0)
Speicherzugriffsfehler (Speicherabzug geschrieben)

ist da irgendetwas bekannt?

Wüsste nicht was da bei dem Chat nicht klappen sollte.

Wenn ich Zugriff habe kann ich anschauen was da gemacht wird (im VDR Code bzw. in unserem Treiber).

Wir supporten (natürlich) auch nur die aktuelle Treiberversion, da diese allen zur Verfügung steht.

Zwischen 2013 - 2021 sind die Unterschiede zu groß (vielleicht nicht im Treiber, aber im Framework).

Nachtrag

wie unterhalb erwähnt der Link, Kanal #sundtek

Der Webchat geht jetzt wieder der Freenode Link wurde auf libera.chat geändert

(bin aber für heut nicht mehr online).

Der Web-Chat ist nun auf irc.libera.chat #sundtek

Quote from MarkusE

Hi,

Das neu bauen half nicht. Der Fehler tritt wieder auf. Vermutlich ist es der Sundtek Treiber:

https://support.sundtek.de/chat.php

Du kannst ja mal vorbeischauen, dann kann ich mir das eventuell bei Dir ansehen. Aktuell ist da eigentlich kein Problem bekannt (und alle Kunden der letzten 12 Jahre verwenden den gleichen Treiber).

Wie sieht deine sundtek.conf aus?

Die CPU Auslastung ist immer etwas relativ, 80% von einem runtergetakteten System wäre jetzt nicht viel.

Ansosnten einfach die Signalstatistiken mitlaufen lassen (die sind pro Transponder/Frequenz und nicht für den gesamten Satelliten):

/opt/bin/mediaclient --readsignal=0 -d /dev/dvb/adapter0/frontend0 --band universal

Quote from rell

HelmutB Danke. Die retune Geschichte scheint gelöst, das 4098/4096 Problem ist nach wie vor da. Noch eine Idee? Ich schau selber auch mal in den Code um das zu verstehen, zumindest es zu versuchen.

Wegen der Empfangsqualität weiß ich nicht, ob die wirklich schlecht ist.

Der BER Wert z.B. geht nur beim Frequenzwechsel kurzzeitig hoch, sonst sehen alle Werte unverfächtig aus. Ist das normal?

Wo wäre anzusetzen auf dem Weg von LNB - Kabel - Multischalter - Kabel - Sundtek - USB - Kabel - Server? Wobei ich nicht glaube, da viel verbessern zu können/müssen.

Gruß Andreas

Sind das passiv-Switches? bzw. der Tuner versorgt das Switch und den LNB mit Strom?

Die SkyTV 4rer könnten bei so einer Nutzung eventuell Hitzeprobleme bekommen.

Erst ab SkyTV 5 wurden andere LNB Spannungsversorgungen verwendet die mehr Strom liefern können.

Andererseits könnte der LNB eventuell auch die Frequenzen shiften (je nachdem wie alt er ist), ich würde das Switch erst mal weglassen und den LNB direkt ansteuern.

Danke für Deine Arbeit!

Quote from seahawk1986

Ich habe mal begonnen die Pakete für experimental-main über amd64, armvh und arm64 hinweg bauen zu lassen bzw. die Architekturen einzugrenzen, wenn etwas nicht bau- bzw. Nutzbar ist: https://launchpad.net/~seahawk…/ubuntu/experimental-main

Das ist lange noch nicht fertig (u.a. muss ich das Paket für den sundtek-Treiber überarbeiten, damit abhängig von der Architektur die passenden Dateien genutzt werden), aber eventuell hilft das dir schon mal weniger Pakete bauen zu müssen (für die ARM-Architekturen dauert das bei Launchpad im Vergleich zu amd64 immer deutlich länger).

Du kannst ja auch unseren Installer direkt verwenden? Wenn Du irgendwelche Zusatzfeatures benötigst können wir das durchaus dort auch reinbauen.

Ja Dual DVB-S/S2/S2X sind vorrätig.

Quote from jrie

Die DD Treiber werden hauptsächlich von Ralph Metzler ( rjkm) entwickelt.

Wegen Ärger mit Mauro Chehab werden die aber schon lange nicht mehr eingereicht.

nst hat es auf sich genommen, die DD Treiber auf der kernel-media Liste einzureichen.

Vor 2 Jahren hatte er dann aber auch von Mauro genug.

Sein git gibt es noch.

Deshalb haben wir vor 12 Jahren bereits Treiber in's Userspace verfrachtet und das komplette Framework dort auch neu entwickelt um keine Abhängigkeiten mehr zu haben.

Es brachte viele Vorteile mit sich, vor allem was die Kompatibilität anging. Ein Treiber Binary für Linux 2.6.16 (2006!)- 5.x, und neue Versionen müssen wir auch nicht beachten.

Das Build System benötigt bei uns gute 5-10 Minuten um Treiber für X86, ARM, MIPS, PPC, SH4 (und deren verschiedenen Variationen) zu erstellen und zu deployen.

Kunden starten einfach das (einmal heruntergeladene) Netinstall-Skript und das zieht sich immer den aktuellen Treiber, auf allen Architekturen.

Und das gilt auch nach wie vor für 12 Jahre alte Tuner.

Diverse Distributionen haben das Netinstall Skript auch integriert, oder greifen direkt auf die fertigen Treiber zu.

Auch beisst sich die Geschichte nicht mit anderen Webcam/DVB Treibern die es im Kernel gibt, da wir die ja überhaupt nicht anrühren.

Der Dual S2 USB Tuner ist n Tuner für die Hosentasche

Quote from seahawk1986

Oder den mediasrv tatsächlich unter die Kontrolle von systemd stellen:

https://github.com/yavdr/yavdr…ystemd/sundtek.service.j2 - dazu muss man dann allerdings die udev-Regel übersteuern, die vom sundtek-Treiber installiert wird, damit der mediaclient nicht dazwischen funkt.

Mit dem --wait-for-devices Flag blockiert der Treiber dann so lange bis alle Geräte initialisiert wurden.

Das Dynamite Plugin ist die beste Wahl.

Eine Möglichkeit den VDR zu initialisieren sobald der Tuner verfügbar ist:

/etc/sundtek.conf

device_attach=service vdr restart