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):
==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
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
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!
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.
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 
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
Alles anzeigenDas war wohl ein Aprilscherz
Mein im Februar getätigte Bestellung wurde wohl storniert. Zumindest gab es eine PayPal Rückzahlung.
Kommentarlos, auf direkte Nachfrage gab es auch keine Antwort.
So wie ich das sehe gibt es nicht wirklich alternative dual DVB-C Hardware...
Offtopic zuende.
So langsam nerven mich die Störungen/Klötzchen im Bild!
Schau mal in die Email.
Die Dual Tuner sind nicht abgesagt, wir müssen noch etwas mehr testen da es diese Woche große Treiberänderungen gab die zum Teil große Änderungen mit sich gebracht haben, ob's eine neue HW Revision gibt wird dann in den kommenden Tagen festgelegt. Ein paar Tuner haben wir ja noch fertig bestückt (welche während der Tests aber erst mal den Testern vorbehalten sind).
Der Chiphersteller hat uns zur Zeit auch auf dem Radar mit den Geräten und will da bei den Kabelnetzen bei denen wir Zugriff haben auch noch etwas überprüfen.
Genauere Antworten gibt's dann im Laufe der nächsten Werk-Tage.
Einen kleinen Fehler im Patch hätte ich schon gefunden: statt "%ld ms" sollte es "%lu ms" für den uint64_t Rückgabewert von Elapsed() sein (auf einem 64-Bit System, "%llu" bei 32-Bit).
Für sowohl 32 als auch 64 Bit sollte "lld" mit (unsigned long long) typecast gehen.
dsyslog(">>> %s(%d/%d): %llu ms (18V->13V)", __func__,adapter, frontend, (unsigned long long)ExecTimer.Elapsed())
Schau dir mal inttypes.h an
%"PRIu64"
Alles anzeigenHallo Helmut,
ich kann hier ähnliches berichten.
Der Matrix VDR mit einer FFHD6400 erzeugt nicht so viele Diseqc-re-send Befehle, als der RaspberryPi mit USB-DVB-Tuner.Beide VDR’s waren heute knapp 6h mit EPG-Scan aktiv, Resultat siehe unten.
Aber der Patch funktioniert sehr gut!Man bekommt kein Blackscreen, wenn es mal beim zappen zum „re-send Diseqc“ kommen sollte.
Vielen Dank für den Patch an HelmutB und kls !
CodeApr 15 12:54:55 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 111053 for channel 16 (ONE HD) - re-sending SCR command Apr 15 13:55:46 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 111362 for channel 2 (ZDF HD) - re-sending SCR command Apr 15 14:49:03 raspberrypi vdr: [769] frontend 0/0 did not switch to transponder 211971 for channel 41 (MTV) - re-sending SCR command Apr 15 14:51:19 raspberrypi vdr: [769] frontend 0/0 did not switch to transponder 211347 for channel 14 (ZDFinfo HD) - re-sending SCR command Apr 15 16:12:15 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 111362 for channel 2 (ZDF HD) - re-sending SCR command Apr 15 16:12:50 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 111493 for channel 1 (Das Erste HD) - re-sending SCR command Apr 15 16:15:14 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 112226 for channel 34 (Eurosport 1 Deutschland) - re-sending SCR command Apr 15 16:21:51 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 111302 for channel 11 (ServusTV HD Deutschland) - re-sending SCR command Apr 15 18:49:30 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 112460 for channel 10 (SIXX) - re-sending SCR command Apr 15 19:08:07 raspberrypi vdr: [771] frontend 1/0 did not switch to transponder 112188 for channel 4 (RTL Television) - re-sending SCR command
CodeApr 15 14:37:30 matrix-vdr vdr: [797] frontend 1/0 did not switch to transponder 111053 for channel 16 (ONE HD) - re-sending SCR command Apr 15 16:59:22 matrix-vdr vdr: [797] frontend 1/0 did not switch to transponder 211624 for channel 39 (CNN Int.) - re-sending SCR command Apr 15 17:20:05 matrix-vdr vdr: [797] frontend 1/0 did not switch to transponder 111302 for channel 11 (ServusTV HD Deutschland) - re-sending SCR command Apr 15 19:03:55 matrix-vdr vdr: [797] frontend 1/0 did not switch to transponder 111362 for channel 2 (ZDF HD) - re-sending SCR command
Der Tuner auf dem Matrix blockiert ja auch die Leitung bei Dir.
Ich weiß nicht wie es bei den anderen Tunern mit den Timings aussieht, eventuell haben diese auch Sleeps in den Treibern wenn sie die Spannungsversorgung hochdrehen (eventuell um sicherzugehen dass dann wirklich 18 oder 13V an der Leitung anliegen).
Das Re-Tune ist ja nur der "After"-Effekt wo die Leitung bereits belegt war.
Muss sagen ihr habt da wirklich eine gute Arbeit geleistet
Schöne Ostern dann noch!
