Posts by Fourty2

Fourty2 · 2019-05-19T23:29:05+01:00

Ich hab das spezielle Problem mal vor einiger Zeit so gelöst:

Eintrag in reccomands zur Anzeige:

TS-Errors: f() { /bin/cat $1/TS-Errors.log; }; f

Recording hooks Script, prüft auf TS-Fehler nach Schnitt und sorgt dafür, daß "alles" bei der Aufnahme bleibt:

Code

case $1 in
[..]
edited)
# do here whatever you would like to do right AFTER
# the recording $3 has been EDITED (path is $2)
copyepgimages "$3" "$2" "$3"
[ -f "${3}/info.epg2vdr" ] && cp "${3}/info.epg2vdr" "${2}/"
[ -f "${3}/TS-Errors.log" ] && cp "${3}/TS-Errors.log" "${2}/"
if [ ! -f "${3}/TS-Errors.log" ]; then
vdr-checkts "${2}" > "${2}/TS-Errors.log" &
fi
;;
*)

Display More

HTH,

Stefan

Fourty2 · May 13th 2019

Hab das schon seit VDR... 1.2(?) (also, seit ausreichend Speicher da war) so gepatched, sonst klemmte immer irgendwas - Parallelaufnahmen, Netzwerk-I/O oder Markad/Noad...

Diff

--- a/recorder.c
+++ b/recorder.c
@@ -10,7 +10,7 @@
#include "recorder.h"
#include "shutdown.h"
-#define RECORDERBUFSIZE (MEGABYTE(20) / TS_SIZE * TS_SIZE) // multiple of TS_SIZE
+#define RECORDERBUFSIZE (MEGABYTE(100) / TS_SIZE * TS_SIZE) // multiple of TS_SIZE
// The maximum time we wait before assuming that a recorded video data stream
// is broken:
--- a/dvbdevice.c
+++ b/dvbdevice.c
@@ -2298,7 +2298,7 @@
CloseDvr();
fd_dvr = DvbOpen(DEV_DVB_DVR, adapter, frontend, O_RDONLY | O_NONBLOCK, true);
if (fd_dvr >= 0)
- tsBuffer = new cTSBuffer(fd_dvr, MEGABYTE(5), CardIndex() + 1);
+ tsBuffer = new cTSBuffer(fd_dvr, MEGABYTE(25), CardIndex() + 1);
return fd_dvr >= 0;
}
--- a/dvbplayer.c
+++ b/dvbplayer.c
@@ -230,7 +230,7 @@
// --- cDvbPlayer ------------------------------------------------------------
-#define PLAYERBUFSIZE MEGABYTE(1)
+#define PLAYERBUFSIZE MEGABYTE(10)
#define RESUMEBACKUP 10 // number of seconds to back up when resuming an interrupted replay session
#define MAXSTUCKATEOF 3 // max. number of seconds to wait in case the device doesn't play the last frame

Display More

Stefan

Fourty2 · May 1st 2019

kamel5 wrote:

Sobald ich versuche Timeshift oder eine Aufnahme zu starten, gibt es eine Fehlermeldung, das der Pay-TV Anbieter das gesperrt hat. Versucht habe ich das auf verschiedenen Kanälen, immer das Gleiche.

Dachte ich mir. Dem CAM mit ARM7TDMI CPU auf eCos 2.2.0 geht dabei jedenfalls nicht die Puste aus. Das ACL hat auch keine großartig andere Hardware.

Bleibt nur die minimal benötigten Streams verschlüsselt zu speichern und anschließend zu entschlüsseln. Das wäre ja "nur" ein etwas ausladender Cache, sozusagen. Und es wären auch sicher keine irgendwie illegalen CW Logs nötig - bleibt ja alles im Modul.

Aber schade, daß das CI+ derart zugenagelt ist.

42.

Fourty2 · Apr 30th 2019

jsffm wrote:

Das ist genau der Punkt, die Entschlüsselung müsste zeitnah geschehen.

Nein. Denke nicht.

Soweit ich weiß, entschlüsselt die Karte auch "alte" ECM Streams (die passende ECM Pid muß man natürlich mitspeichern). Der Original-Receiver legt die Dateien auch "verschlüsselt" ab und jagt sie bei Wiedergabe jedesmal erneut durch das Smartkärtchen.

Was nicht geht ist ECMs mit Datum > Ablaufdatum zu dekodieren. Logisch...

Wenn die 90 Minuten Begrenzung bei der Vue greifen würde ... würde man das als Einschränkung sicher irgendwo lesen.

42

Fourty2 · Apr 29th 2019

Das wird wohl der Grund sein, warum neuere Vue-Boxen den TS-Stream aufnehmen und "offline", also wenn das Modul gerade nicht live gebraucht wird, entschlüsseln können.

Könnte man dem VDR natürlich auch beibringen - wäre aber, denke ich, eine größere Umbauaktion.

Fourty2 · Apr 29th 2019

Das ist das offizielle Sky Modul, was man für EUR 99,- "Leihgebühr" ... lassen wir das.

Technisch könnte das Modul, wenn es dürfte. Dann ist es wohl seitens Sky geblockt.

Zum Thema Timeshift:
Müßte Kamel5 mal in ein CI+ TV stecken und testen. Könnte mir aber vorstellen, daß man nur "Pause" drücken darf. Man soll ja den zahlenden Kunden nicht zuviel Freiheiten lassen.

Grüße,

42

Fourty2 · Apr 28th 2019

kamel5 :
Hast Du mal die Patche für nicht MTD meldende CAMs probiert?

~42

Fourty2 · Apr 26th 2019

Nein. Nein...

Das Ausschalten der CW-CRC Prüfung hilft nur den Wenigen mit "ohne Hardwarezuordnung".

Gleiches gilt für den (i==12) Freezer-Fix.

Da er statt einem CI+ Modul, das zumindest mit dem VDR verwendbar wäre, eine Kuh hat, ist die Karte (jetzt) sicher verheiratet. Da ist ohne den allgemeinen oder besonderen CW-Schlüssel (erstmal) Ende Gelände für die Software-Lösung.

Hardware-CAMs, die die CRCs prüfen, oder einfach neu berechnen und überschreiben, funktionieren jetzt halt ebenso nicht mehr, bis das ein Firmware-Update ggf. richtet.

Also besser das CI+ nehmen, wenn man VDR und Himmels-Nutzer bleiben will und nicht zu den Turings dieser Welt gehört.

Stefan

PS: Hoffe, das war jetzt noch auf erlaubten Seite...

Fourty2 · Apr 25th 2019

Hallo Marcus,

wenn, geht es vermutlich nur per epgd / epg2vdr, indem Du die Channel-ID des IP-TVs halt zu den jeweiligen Sat-Channel IDs schreibst.

Grüße,

Stefan

Fourty2 · Apr 19th 2019

Die Prüfsumme der CWs kann nicht mehr per (CW[Byte 0] + [CW[Byte 1] + CW[Byte 2]) & 0xFF = CW[Byte 3] geprüft werden. Damit fällt alles auf die Nase, was die CRC/Prüfsumme prüft und Falsche verwirft.

Stefan

Fourty2 · Apr 13th 2019

Hallo Klaus,

naja, wenn die Meldung des I²C Timeouts stimmt, hält irgendein Stück der Hardware die I²C CLK und/oder DTA auf Masse und ist in diesem Zustand abgestürzt.
D.h. die I²C Takt- und/oder Datenleitung ist vom (abgestürzten) I²C-Slave auf Masse gezogen worden (Clockstretch / ACK) und noch immer dort.
Falls ein ACK-Hänger (Data = Lo) vorliegt, helfen eventuell manuelle CLK-Pulse. Ist die CLK auf Masse (Clock-Stretch), ist Ende-Gelände bis zum Hardware-Reset (oder Power-Off).

Stefan

Fourty2 · Feb 7th 2019

Hallo zusammen,

seit einem Update der MariaDB in debian buster bekommen ich beim epg2vdr compilieren folgenden Fehler:

Code

db.c: In member function 'int cDbConnection::errorSql(cDbConnection*, const char*, MYSQL_STMT*, const char*)':
db.c:1382:17: error: 'CR_INVALID_CONN_HANDLE' was not declared in this scope
error == CR_INVALID_CONN_HANDLE ||
^~~~~~~~~~~~~~~~~~~~~~
db.c:1382:17: note: suggested alternative: 'CR_INVALID_BUFFER_USE'
error == CR_INVALID_CONN_HANDLE ||
^~~~~~~~~~~~~~~~~~~~~~
CR_INVALID_BUFFER_USE
db.c:1386:17: error: 'CR_CONN_UNKNOW_PROTOCOL' was not declared in this scope
error == CR_CONN_UNKNOW_PROTOCOL ||
^~~~~~~~~~~~~~~~~~~~~~~
db.c:1386:17: note: suggested alternative: 'CR_CONN_UNKNOWN_PROTOCOL'
error == CR_CONN_UNKNOW_PROTOCOL ||
^~~~~~~~~~~~~~~~~~~~~~~
CR_CONN_UNKNOWN_PROTOCOL
make[2] *** [Makefile:86: db.o] Fehler 1

Display More

Einfach mit "suggested alternative" ersetzen, oder ist da Nacharbeit erforderlich?

Stefan

Fourty2 · Jan 19th 2019

Hallo zusammen,

hab da noch einen Segfault im epg2vdr, wenn man beim Starten ein paar Tasten zuviel drückt:

Code

Thread 26 "epg2vdr-update" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fbc577fe700 (LWP 8094)]
cUpdate::updateRecordingTable (this=this@entry=0x55b16b6db8c0, fullReload=<optimized out>) at lib/db.h:681
681 cDbValue* getValue(const char* n) { GET_FIELD_RES(n, 0); return &dbValues[f->getIndex()]; }
(gdb) bt
#0 0x00007fbcc23f2ab9 in cUpdate::updateRecordingTable(int) (this=this@entry=0x55b16b6db8c0, fullReload=<optimized out>) at lib/db.h:681
#1 0x00007fbcc23ddd82 in cUpdate::Action() (this=0x55b16b6db8c0) at update.c:1347
#2 0x000055b169c213a1 in cThread::StartThread(cThread*) (Thread=0x55b16b6db8c0) at thread.c:293
#3 0x00007fbcced22fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#4 0x00007fbcce61a7ef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb)

Display More

Ideen?

Stefan

Fourty2 · Jan 7th 2019

kamel5

Ja stimmt, der Patch ist kaputt. Hab mal wieder aus dem Nano kopiert, ohne vorher ESC+$ zu drücken... Arrgh.

Also fehlt, was rechts nicht im Fenster war.

Anbei der komplette Patch (mit entferntem Alt-Code)

Stefan

Fourty2 · Jan 7th 2019

Wenn ich das richtig verstehe, bleibt nach einem Erase lediglich das Start-Element der Iteration gültig.

Ein for() Loop ist demnach eher ungünstig, wenn man alle Elemente löscht.

Hab das jetzt mal so gepachted - so läuft es erstmal und scheint noch zu funktionieren.

Diff

--- a/conflictcheck.c
+++ b/conflictcheck.c
@@ -584,12 +584,23 @@
LogFile.Log(3, "add pending timers");
// if we have pending timers add them to the current start list
+ it = pendingTimers.begin();
+ while (it != pendingTimers.end())
+ {
+ if ((*it) && (*it)->stop > checkTime->evaltime)
+ checkTime->startingTimers.insert(*it);
+ pendingTimers.erase(*it);
+ it = pendingTimers.begin();
+ }
+
+/*
for (it = pendingTimers.begin(); it != pendingTimers.end(); ++it) {
if ((*it) && (*it)->stop > checkTime->evaltime)
checkTime->startingTimers.insert(*it);
pendingTimers.erase(*it);
}
+*/
LogFile.Log(3, "attach starting timers");
// handle starting timers
for (it = checkTime->startingTimers.begin(); it != checkTime->startingTimers.end(); ++it) {
@@ -600,12 +611,20 @@
if (NeedsDetachReceivers) { // but needs to detach all others?
// disable running timers
std::set<cConflictCheckTimerObj*, TimerObjSort>::iterator it2 = devices[device].recTimers.begin();
- for (; it2 != devices[device].recTimers.end(); ++it2) {
+ while (it2 != devices[device].recTimers.end()) {
+ LogFile.Log(3, "stopping timer '%s' (%s, channel %s) at %s on device %d because of higher priority", (*it2)->timer->File(), DAYDATETIME((*it2)->start), CHANNELNAME((*it2)->time$
+ AddConflict((*it2), checkTime, pendingTimers);
+ devices[device].recTimers.erase(*it2);
+ it2 = devices[device].recTimers.begin();
+ Conflicts++;
+ }
+/* for (; it2 != devices[device].recTimers.end(); ++it2) {
LogFile.Log(3, "stopping timer '%s' (%s, channel %s) at %s on device %d because of higher priority", (*it2)->timer->File(), DAYDATETIME((*it2)->start), CHANNELNAME((*it2)->time$
AddConflict((*it2), checkTime, pendingTimers);
devices[device].recTimers.erase(*it2);
Conflicts++;
}
+*/
}
devices[device].recTimers.insert(*it);
(*it)->device = device;

Display More

Stefan

Fourty2 · Jan 6th 2019

Hab noch einen neuen Segfault (nach Auskommentieren des letzten Fehlers oben):

Code

Thread 13 "EPGSearch: conf" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f01b2ffd700 (LWP 11294)]
0x00007f01f16e1458 in cConflictCheck::ProcessCheckTime(cConflictCheckTime*) () from /usr/lib/vdr/plugins/libvdr-epgsearch.so.2.4.0
(gdb) bt
#0 0x00007f01f16e1458 in cConflictCheck::ProcessCheckTime(cConflictCheckTime*) () at /usr/lib/vdr/plugins/libvdr-epgsearch.so.2.4.0
#1 0x00007f01f16e15a4 in cConflictCheck::CreateConflictList(cList<cConflictCheckTime>*, cList<cConflictCheckTimerObj>*) () at /usr/lib/vdr/plugins/libvdr-epgsearch.so.2.4.0
#2 0x00007f01f16e1814 in cConflictCheck::Check() () at /usr/lib/vdr/plugins/libvdr-epgsearch.so.2.4.0
#3 0x00007f01f16e3277 in cConflictCheckThread::Action() () at /usr/lib/vdr/plugins/libvdr-epgsearch.so.2.4.0
#4 0x0000557ae6df83a1 in cThread::StartThread(cThread*) (Thread=0x557ae7dfe2a0) at thread.c:293
#5 0x00007f01fc7b4fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#6 0x00007f01fc0ac88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Display More

Backtrace vom "laufenden Betrieb" der plötzlich (Re-)Startenden Kiste...

Log endet da:

Code

vdr: epg2vdr: Recording of 'It Comes at Night' has 'started' [/srv/vdr/video/local/It_Comes_at_Night/2019-01-06.18.25.100-0.rec]
vdr: [11988] duplicates: Scanning of duplicate recordings started.
vdr: scraper2vdr: Calling mysql_init(11998)
vdr: scraper2vdr: Connection established successfull!
vdr: epg2vdr: Info: Marked 410 recordings as deleted
vdr: [11969] writing timer id '3@roadrunner' to /srv/vdr/video/local/It_Comes_at_Night/2019-01-06.18.25.100-0.rec/.timer
vdr: [11983] EPGSearch: search timer update started
vdr: [11984] EPGSearch: timer conflict check started
==> /var/log/syslog <==
kernel: [25197.506214] EPGSearch: conf[11984] segfault at 1000018 ip 00007f1eba8aa458 sp 00007f1e73ffeba0 error 4 in libvdr-epgsearch.so.2.4.0[7f1eba893000+91000]
kernel: [25197.506235] Code: 89 c3 4c 01 f7 48 8d 47 08 48 39 c3 0f 84 0d fe ff ff 49 8b 75 18 4c 89 ff e8 e4 a6 fe ff 48 8b 45 c8 48 89 45 80 48 8b 43 20 <48> 8b 50 18 48 8b 7a 48 48 85 ff 0f 85 1f ff ff ff 48 8d 15 ea 03
lircd-0.10.1[2307]: Info: removed client
lircd-0.10.1[2307]: Info: closing '/dev/input/event5'
runvdr: restarting VDR

Display More

Stefan

Fourty2 · Jan 2nd 2019

Wir schreiben 2019:

Hochskaliert... autsch.

Fourty2 · Jan 1st 2019

seahawk1986

Ja, war definitiv das udev, was wohl im "noch nicht so ganz bereiten" Zustand angesprochen wurde.

Downgrade auf 239 oder ein Delay im Init-Script behebt das Problem (bei mir).

Kernel kann ich ausschließen ... wird hier selbst aus dem GIT gebacken und aus eigenem Repository installiert.

Dies hier halt:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917247

System ist ein Intel J3160 mit TT-budget S2-4200 Twin - also alles im Kernel 4.19.13.

Und als aplay -lL "keine Audio Geräte" mehr meldete, war klar, was schief lief.

Die hätte man sonst vorher aus dem Chipsatz meißeln müssen.

VDR-Log:

Code

[4781] VDR version 2.4.0 started
[4781] switched to user 'vdr'
[4781] codeset is 'UTF-8' - known
[4781] found 28 locales in /usr/share/locale
[4781] loading plugin: /usr/lib/vdr/plugins/libvdr-vaapidevice.so.2.4.0
[4781] loading plugin: /usr/lib/vdr/plugins/libvdr-dvbapi.so.2.4.0
[4781] loading plugin: /usr/lib/vdr/plugins/libvdr-remote.so.2.4.0
[4781] loading plugin: /usr/lib/vdr/plugins/libvdr-epgsearch.so.2.4.0
[4781] loading plugin: /usr/lib/vdr/plugins/libvdr-skinnopacity.so.2.4.0
[4781] loading plugin: /usr/lib/vdr/plugins/libvdr-externalplayer.so.2.4.0
[4781] loading plugin: /usr/lib/vdr/plugins/libvdr-osdteletext.so.2.4.0
[4781] loading plugin: /usr/lib/vdr/plugins/libvdr-undelete.so.2.4.0
[4781] loading plugin: /usr/lib/vdr/plugins/libvdr-devstatus.so.2.4.0
[4781] loading plugin: /usr/lib/vdr/plugins/libvdr-femon.so.2.4.0
[4781] loading plugin: /usr/lib/vdr/plugins/libvdr-recsearch.so.2.4.0
[4781] loading plugin: /usr/lib/vdr/plugins/libvdr-dvdswitch.so.2.4.0
[4781] loading plugin: /usr/lib/vdr/plugins/libvdr-live.so.2.4.0
[4781] loading plugin: /usr/lib/vdr/plugins/libvdr-dvd.so.2.4.0
[4781] loading plugin: /usr/lib/vdr/plugins/libvdr-radio.so.2.4.0
[4781] loading plugin: /usr/lib/vdr/plugins/libvdr-markad.so.2.4.0
[4781] loading plugin: /usr/lib/vdr/plugins/libvdr-duplicates.so.2.4.0
[4781] loading plugin: /usr/lib/vdr/plugins/libvdr-streamdev-server.so.2.4.0
[4781] loading plugin: /usr/lib/vdr/plugins/libvdr-suspendoutput.so.2.4.0
[4781] loading plugin: /usr/lib/vdr/plugins/libvdr-epgborder.so.2.4.0
[4781] loading plugin: /usr/lib/vdr/plugins/libvdr-epg2vdr.so.2.4.0
[4781] loading plugin: /usr/lib/vdr/plugins/libvdr-scraper2vdr.so.2.4.0
[4781] loading /var/lib/vdr/setup.conf
[..]
[4781] no DVB device found
[..]
[4781] ERROR: invalid primary device number: 3
[4781] trying device number 1 instead
[4781] setting primary device to 1
[4781] assuming manual start of VDR
[4781] skin "nOpacity" not available - using "lcars" instead
[4783] epg data reader thread started (pid=4781, tid=4783, prio=high)
[4781] starting plugin: vaapidevice
[4783] reading EPG data from /var/cache/vdr/epg/epg.data
[4781] VAAPI: audio: 'alsa' output module used
[4781] VAAPI-ERROR: audio/alsa: playback open 'hdmi:CARD=PCH,DEV=2,AES0=0x04' error: Das Argument ist ungültig
[4781] VAAPI-ERROR: audio/alsa: can't open mixer 'default'
[4781] VAAPI: audio: 44100Hz supports 0 0 0 0 0 0 0 0 channels
[4781] VAAPI: audio: 48000Hz supports 0 0 0 0 0 0 0 0 channels
[4781] VAAPI: audio: 192000Hz supports 0 0 0 0 0 0 0 0 channels
[4781] VAAPI-ERROR: codec: can't allocate HW video codec context
..und Tschüss (so ohne Bild, Ton, und DVB) ;)

Display More

Stefan

Fourty2 · Jan 1st 2019

Hallo zusammen,

irgendwann lerne ich es noch, das VDR-System nicht mehr zu aktualisieren ... ;-/

Das Update auf udev 2.40 hat wohl das System zerlegt. In /dev fehlt eigentlich seit Neustart alles, was ein VDR so braucht. Ganz toll.

Weiß jemand, wo ich mal suchen und reparieren könnte?

Stefan

Edit:
Nach etwas suchen:
- Das udev startet (bei sysv-init) jetzt per start-stop-manager (aber viel zu früh)
- Patch gibt es da: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908796

Fourty2 · Dec 20th 2018

Code

conflictcheck.c: In member function 'int cConflictCheck::ProcessCheckTime(cConflictCheckTime*)':
conflictcheck.c:590:37: error: no match for 'operator=' (operand types are 'std::set<cConflictCheckTimerObj*, TimerObjSort>::iterator' {aka 'std::_Rb_tree_const_iterator<cConflictCheckTimerObj*>'} and 'std::set<cConflictCheckTimerObj*>::size_type' {aka 'long unsigned int'})
it = pendingTimers.erase(*it);
^
In file included from /usr/include/c++/8/set:60,
from conflictcheck.h:30,
from conflictcheck.c:26:
/usr/include/c++/8/bits/stl_tree.h:326:12: note: candidate: 'constexpr std::_Rb_tree_const_iterator<cConflictCheckTimerObj*>& std::_Rb_tree_const_iterator<cConflictCheckTimerObj*>::operator=(const std::_Rb_tree_const_iterator<cConflictCheckTimerObj*>&)'
struct _Rb_tree_const_iterator
^~~~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/8/bits/stl_tree.h:326:12: note: no known conversion for argument 1 from 'std::set<cConflictCheckTimerObj*>::size_type' {aka 'long unsigned int'} to 'const std::_Rb_tree_const_iterator<cConflictCheckTimerObj*>&'
/usr/include/c++/8/bits/stl_tree.h:326:12: note: candidate: 'constexpr std::_Rb_tree_const_iterator<cConflictCheckTimerObj*>& std::_Rb_tree_const_iterator<cConflictCheckTimerObj*>::operator=(std::_Rb_tree_const_iterator<cConflictCheckTimerObj*>&&)'
/usr/include/c++/8/bits/stl_tree.h:326:12: note: no known conversion for argument 1 from 'std::set<cConflictCheckTimerObj*>::size_type' {aka 'long unsigned int'} to 'std::_Rb_tree_const_iterator<cConflictCheckTimerObj*>&&'
make[2] *** [Makefile:193: conflictcheck.o] Fehler 1

Display More

Posts by Fourty2

vdr --genindex

ringbuffer dvbplayer

[Patch] CAM-Tweaks für Multi Channel Decryption

[Patch] CAM-Tweaks für Multi Channel Decryption

[Patch] CAM-Tweaks für Multi Channel Decryption

[Patch] CAM-Tweaks für Multi Channel Decryption

DigitalDevices mit ddci und Sky CI+ ?

[Erledigt] Aktuelle channels.conf inklusive Skü

EPG von Sat Kanäle auf IPTV Kanälen

[Erledigt] Aktuelle channels.conf inklusive Skü

I2C Timeouts mit ddbridge

epg2vdr + MariaDB Update (in debian buster) nicht übersetztbar

epg2vdr (-update) Segfault

[gelöst] epgsearch - segfault seit dem gestrigen Debian Testing update

[gelöst] epgsearch - segfault seit dem gestrigen Debian Testing update

[gelöst] epgsearch - segfault seit dem gestrigen Debian Testing update

ARD-alpha HD - channels.conf Eintrag für DVB-S2?

(Erledigt) Debian Buster und die Updates... (vermutlich udev)

(Erledigt) Debian Buster und die Updates... (vermutlich udev)

[gelöst] epgsearch - segfault seit dem gestrigen Debian Testing update