Nun, er mag "unseren" API Key nicht mehr.
Problem:
Man kommt - oder zumindest ich - derzeit auch nach Erzeugung eines Accounts, Aufruf des Dashboards und dort API-Key nicht weiter...
Scheint was defekt zu sein. Siehe auch:
https://forums.thetvdb.com/viewtopic.php?f=17&t=60029
Posts by Fourty2
-
-
-
Hallo,
ich nehme dazu reprepro. Eine Anleitung gibt es z.B. auf:
https://www.thomas-krenn.com/d…ro_unter_Ubuntu_erstellen
Grüße,
42 -
Was will mir denn dies sagen:
vdr: codec: can't allocate HW video codec context err ffffffea
Ist ein älterer "Intel(R) Celeron(R) CPU J3160 @ 1.60GHz (family: 0x6, model: 0x4c, stepping: 0x4)"Display MoreCode- vainfo: VA-API version: 1.6 (libva 2.4.0)
- vainfo: Driver version: Intel i965 driver for Intel(R) CherryView - 2.4.0.pre1 (2.3.0-22-g9bc30a0)
- vainfo: Supported profile and entrypoints
- VAProfileMPEG2Simple : VAEntrypointVLD
- VAProfileMPEG2Simple : VAEntrypointEncSlice
- VAProfileMPEG2Main : VAEntrypointVLD
- VAProfileMPEG2Main : VAEntrypointEncSlice
- VAProfileH264ConstrainedBaseline: VAEntrypointVLD
- VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
- VAProfileH264Main : VAEntrypointVLD
- VAProfileH264Main : VAEntrypointEncSlice
- VAProfileH264High : VAEntrypointVLD
- VAProfileH264High : VAEntrypointEncSlice
- VAProfileH264MultiviewHigh : VAEntrypointVLD
- VAProfileH264MultiviewHigh : VAEntrypointEncSlice
- VAProfileH264StereoHigh : VAEntrypointVLD
- VAProfileH264StereoHigh : VAEntrypointEncSlice
- VAProfileVC1Simple : VAEntrypointVLD
- VAProfileVC1Main : VAEntrypointVLD
- VAProfileVC1Advanced : VAEntrypointVLD
- VAProfileNone : VAEntrypointVideoProc
- VAProfileJPEGBaseline : VAEntrypointVLD
- VAProfileJPEGBaseline : VAEntrypointEncPicture
- VAProfileVP8Version0_3 : VAEntrypointVLD
- VAProfileVP8Version0_3 : VAEntrypointEncSlice
- VAProfileHEVCMain : VAEntrypointVLD
- ```
- ##### ffmpeg
- ```
- ffmpeg version 4.1.4-1~deb10u1 Copyright (c) 2000-2019 the FFmpeg developers
- built with gcc 8 (Debian 8.3.0-6)
- libavutil 56. 22.100 / 56. 22.100
- libavcodec 58. 35.100 / 58. 35.100
- libavformat 58. 20.100 / 58. 20.100
- libavdevice 58. 5.100 / 58. 5.100
- libavfilter 7. 40.101 / 7. 40.101
- libavresample 4. 0. 0 / 4. 0. 0
- libswscale 5. 3.100 / 5. 3.100
- libswresample 3. 3.100 / 3. 3.100
- libpostproc 55. 3.100 / 55. 3.100
Stefan
-
EPG kam ganz normal über SAT.
Wenn man die Cinemagic Zeile in der EPGD Channelmap ändert, muß man natürlich den DIenst mal neu starten und etwas warten, bis es im vdr "zurück" ist... (bis es mal eine externe ID gibt).
Stefan
-
Du meinst also tatsächlich, die Netzwerk-Infrastruktur braucht, unabhängig von der transportierten Datenmenge, immer dieselbe Energie? Egal ob Idle oder Vollast?
Das wäre schön. Ist aber nicht so. Jedes einzelne Bit, das umgeladen werden muß, fordert Tribut. Und dann wären da noch die USVs, die Klimatisierung und und und...
Nein. Streaming ist im Vergleich zu einer Sat-Abstrahlung eine "Umweltsauerei" erster Güte.Stefan
-
Hast Du mal versucht, die Lade-Reihenfolge der Plugins zu ändern?
Vielleicht schafft das die nötige Zeit, um das Problem zu umschiffen.
Mit epgsearch vor skinnopacity gibt es hier zumindest keine GPFs, maximal WDT Panics, wenn zwei Aufnahmen laufen (sollen) die alle Karten belegen und ... der VDR auf einem dritten Transponder steht.Stefan
-
Ja, geht halt nicht ... schade, aber, als ich damals die Ursache selbst gesucht habe, schien mir das Arbeit/Nutzen-Verhältnis arg ungünstig.
Hab daher das VPS im VDR deaktiviert. Die ein/zwei Aufnahmen im Jahr, bei denen VPS möglich wäre, werden dann halt auch mit + 15 Min aufgenommen.Stefan
-
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:
Display MoreCode- 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
- ;;
- *)
HTH,Stefan
-
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...
Display MoreDiff- --- 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
Stefan
-
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.
-
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
-
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.
-
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
-
-
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... -
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
-
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
-
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
-
Hallo zusammen,
seit einem Update der MariaDB in debian buster bekommen ich beim epg2vdr compilieren folgenden Fehler:
Display MoreCode- 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
Einfach mit "suggested alternative" ersetzen, oder ist da Nacharbeit erforderlich?
Stefan
