Sundtek Support Forum

Leider muss ich dem Widersprechen, die Funktion
/opt/bin/mediaclient --tsprogram 53002 -d /dev/dvb/adapter0/dvr0 > video.m2t
hat - zumindest auf einem Raspi 4 - viel zu niedrige Bitraten (zwischen 240 und 750 kib/s)

Daher habe ich einen Filter geschrieben, der bei SD einen Durchsatz von 2-3 Mib/s hat, bei HD Sendern bis zu 7 Mib/s.
Der Code ist OpenSource und liegt hier https://github.com/kanehekili/MicroDVBRecorder/blob/master/VideoRecorder/src/bin/tspidfilter.c
Im gleichen Verzeichnis gibt es auch noch ein shell script, das die mediaclient commands aufruft.
Eine Beschreibung  gibt es hier: https://github.com/kanehekili/MicroDVBRecorder/blob/master/VideoRecorder/src/xmltv/NOTES.md

Ich möchte mich für den Support bedanken - und vielleicht könnt Ihr ja was mit meinem Code anfangen 

Hallo Sundtek, danke für die schnelle Antwort.
Schreiben tue ich auf eine externe USB3 SSD (mein typo) - mit >70 mib/s sind wir da vollkommen aus dem Schneider.
Meine Tests mit dem mediaclient haben Schreibraten um die 70kb/s angezeigt - für SD Kanäle

summary: 2136 kiByte in 30.1sec - average of 71.0 kiB/s

Mediaclient log hat während der Aufnahmen nichts geschrieben - und damit klärt sich der Fehleintrag "bitstream synchronisation is lost"  im ts file nicht. Dieser Fehler ist vermutlich für die Blockartefakte (Meist kurz vor dem I Frame - wenn halt die vollen Daten kommen) (ohne das verbose flag)

Warum czap und nicht mediaclient? (wir hatten die Diskussion bereit vor 3 Jahren) - Mediaclient erzeugt auf einem Arm device - seit Jahren - blockartige Artefakte. Mit czap hatte ich das Problem nie. Auf einem Intelprozessor /Laptop konnte ich das Problem nicht anchvollziehen (Distro war in jedem Fall Arch Linux /Archarm - kein debian)

Auf einem alten cubieboard sind noch die alten Treiber und czap enthalten - damit funktioniert der Stick einwandfrei (mit czap - mit mediaclient nur mit Artefakten).
Es wäre schön, wenn wir da eine Lösung fänden.

Ich habe folgendes setup:
mediasrv läuft (2 instanzen - ist das richtig??) und nutzte bis letzte Woche czap zum tunen und aufnehmen auf einem cubieboard (arm).

Nach dem letzten update czap neu kompiliert. Beim Aufruf von czap kommt der Fehler /dev/dev/adapter0/frontend0 device not found.

ls /dev/dvb/adapter0/ -la zeigt das device an - es ist also da.

Verwende ich den mediaclient zu Aufnahme kommt es zu Artefakten - diese konnte ich mit czap nicht erkennen. Es muss also bei der Aufnahme via mediaclient (vielleicht von mir) Latenzen o.ä geben, die czap nicht erzeugt.

Aktuell mache ich die Aufnahme via Mediaclient wie folgt:
1) tuning:
/opt/bin/mediaclient -m DVBC -f "$freq" -M "$qam" -S "$symbolrate" &

2) recording
/opt/bin/mediaclient --tsprogram "$progID" -d /dev/dvb/adapter0/dvr0 > target.m2ts

D.h um eine Aufnahme zu machen, benötige ich 2 Prozesse. Die o.a Werte werden aus einer channel.conf ausgelesen - funktioniert.

Mit czap  und cat sind auch 2 Prozesse notwendig, möglicherweise sind die leichtgewichtiger.
Das Thema hatte ich übrigens hier schon mal angesprochen: hier

Im Grunde ergeben sich 2 Fragen:
a) Warum erkennt czap das frontend nicht (mehr) hier
b) Gäbe es eine effektivere Methode den mediaclient zur Aufnahme zu verwenden.

**Update**
Neubau der linuxtv-dvb-apps-1504-1 hat funktioniert (mit patches von 1505-2). Die Version 1505-2 erkennt scheinbar nicht die vom mediasrv bereitgestellten devices. (adapter0/frontend0) 
Falls Interesse besteht, würde ich mal ein diff der beiden sourcefiles machen...

{c}zap funktioniert nicht mehr auf armhf SOCs.    Hier funktioniert - GROSSES LOB - der mediaclient ohne Probleme!
Bislang hatte ich mit {c}zap getuned, und dann über cat das Programm aufgenommen. Die dvb-app Suite funktioniert auf arch linux arm nicht mehr.
Lösung (Basis ist immer noch channels.conf, erzeugt von "wscan"):

• /opt/bin/mediaclient -d /dev/dvb/adapter0/frontend0 -m DVBC -D DVBC -f 394000000 -M Q256 -S 6900000
   /opt/bin/mediaclient --tsprogram 53602 -d /dev/dvb/adapter0/dvr0 > Test.m2t

Basis ist die Zeile im channels.conf:
SUPER RTL:394000000:INVERSION_AUTO:6900000:FEC_NONE:QAM_256:1501:1502:53602

Dazu werde ich ein plugin schreiben. Bei Interesse eines Recorders: https://github.com/kanehekili/MicroDVBRecorder - wird demnächst den mediaclient unterstützen - auf arm 

Möglich.
Habe den sundek.service gestoppt. Als root ausgeführt:

./sundtek_netinst.sh -u

./sundtek_netinst.sh -service

Dann gibt es bereits einen Coredump, wenn man sich systemctl status sundtek.service anschaut..
Bislang ging das immer so.  Frage: Wo kann ich denn eine alten Treiber herbekommen (damit mein Recorder wieder läuft?)

Hier noch meine config:

cat /etc/sundtek.conf
ir_disabled=1
usb_transaction_delay=10
initial_dvb_mode=DVBC
disable_atv=1
ts_settle_timeout=50

Hi
nach dem letzten update läuft der mediaclient service nicht mehr auf meinem Arm Rechner. Service mit systemctl gestartet. Wird z.B /opt/bin/mediaclient -l eingegeben:

Using device: /dev/mediainput0
device: /dev/mediainput0 doesn't support the extended media API

/opt/bin/mediaclient --setdtvmode=DVBC
Using device: /dev/dvb/adapter0/frontend0
device: /dev/dvb/adapter0/frontend0 doesn't support the extended media API
Hintergrund ist, das der mediasrv nicht started (im dmesg gab es einen core dump)

Nov 27 21:21:45 cubie systemd[1]: Started Sundtek MediaTV.
Nov 27 21:21:54 cubie systemd-coredump[580]: Process 553 (mediasrv) dumped core.

Installiert wurde der service mit:
./sundtek_netinst.sh -service
um das LD-PRELOAD Problem zu umgehen...

Wird systemctl neu gestartet läuft der service (allerdings kann ich keinen mediasrv mit ps ax sehen

Wird z.b
export LD_PRELOAD=/opt/lib/libmediaclient.so
/opt/bin/mediaclient -D DVBCeingegeben erfolgt ein Core dump.

Bug im armhf treiber??

Gibt es denn die Möglichkeit, den vorherigen Treiber wieder zu laden?

Für Tips wäre ich dankbar

Nein, kein Codec Problem. Es ist das klassische "pixeln", wenn sich die Bilddaten ändern (z.B Überblendung)
Unter windows sollte mir das nicht helfen, da ich die mpg Dateien auch auf Linux Mint getestet habe. VLC bringt ja ohnehin die eigenen Codecs mit, und im Trace erkennt man, das zum Teil I-Frames fehlen...
Kann Euch gerne bei Bedarf ein aufgenommens mpg zukommen lassen.
Und Windows installier ich nicht - deswegen habe ich ein Jahr auf Euren Stick gewartet...

Hallo,

nach dem etwas aufwändigen scannen von DVB-C Kanälen (mit w_scan) und der wirklich leichten Installierung des MediaClients hatte ich gehofft, auf einem Dual Core Rechner HD Sender anschauen bzw aufnehmen zu können. Erstaunlicherweise ist die HD Qualität sehr schlecht.
Hier kurz die Schritte, die ich ausgeführt habe:
w_scan -f c -c DE -X > channels.conf
/opt/bin/mediaclient -D DVBC
czap -r -c channels.conf "ZDF HD"

Das -r flag sollte nun den Ausgang /dev/dvb/adapter0/dvr schalten - was auch geht:
/opt/bin/mediaclient --lc
**** List of Media Clients ****
/dev/dvb/adapter0/frontend0:
  2624 ... czap
/dev/dvb/adapter0/dvr0:
  2626 ... cat
/dev/dvb/adapter0/demux0:
  2624 ... czap (17de)
  2624 ... czap (17e8)
Um den Kanal aufzunehmen:
cat /dev/dvb/adapter0/dvr0 > Test.mpg
Den mplayer mit folgendem Kommando ans fliegen zu bringen, hat nicht funktioniert:
cat /dev/dvb/adapter0/dvr0 | mplayer -cache 10240 -(Es passiert einfach garnichts)

Die aufgenomme Test.mpg Datei (mpg-ts Format) konnte nicht mit dem VLC abgespielt werden.
Mit dem Mplayer war die HD-Datei abspielbar: Ton und sehr schlechtes Bild.

Wird der VLC mit der channels.conf geöffnet und dieser Sender in der Playlist ausgewählt kommen Ton und Bild, aber das Bild ist extrem schlecht.

Die Probleme tauchen bei SD Sendern nicht oder nur gelegentlich auf- die aufgenommenen MPG Dateien können nur mit dem Mplayer abgespielt werden (VLC hat da wohl den Codec nicht)

Laut czap ist der Empfang gut:
status 1f | signal ffee | snr ff8e | ber 00000000 | unc 00000000 | FE_HAS_LOCK
Laut mediaInfo werden folgende mpg Daten erzeugt:
Format MPEG-TS
Profile: No PAT/PMT
Video AVC
Audio AC-3

Meine Fragen sind:
 - Wie kann man die HD Performance verbessern, bzw erkennen, wo der Fehler liegt
 - Kann das auszugebende mpeg Format geändert werden (flags?) oder ist das nur über ffmpeg zu machen?