hi Xcoder,
gibt es neue Erkenntnisse bzgl. des Patches?
Hg
Stephan
hi Xcoder,
gibt es neue Erkenntnisse bzgl. des Patches?
Hg
Stephan
Hi,
der Patch ist doch schon im GIT oder?
CU
9000h
Ja, ist drin. War für Installationen mit mehr als einem Satip-Server relevant.
Weis jetzt aber nicht mehr ob der hier angehängte Patch die letzte Version war. Besser gleich die aktuelle Source von github ziehen.
Leider bekomme ich den Fehler nicht weg ... Kann "
etwas damit zu tun haben?
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] ERROR: Transfer-Mode kann nicht gestartet werden!
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] --- begin invalid lock sequence report
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] 1267 - W - - - - - - - - L
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] 1267 - U - - - - - - - - U
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] 1165 - R - - - - - - - - L
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] 1165 - U - - - - - - - - U
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] 1165 - R - - - - - - - - L
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] 1165 - U - - - - - - - - U
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] 1165 - R - - - - - - - - L
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] 1165 - U - - - - - - - - U
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] 1165 - R - - - - - - - - L
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] 1165 - * - - R - - - - - L
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] 1165 - * - - * - - - - - L
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] 1165 - * - - * - - - - - L
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] 1165 - * - - * - - - - - U
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] 1165 - * - - * - - - - - U
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] 1165 - * - - U - - - - - U
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] 1165 - * - - - - - - - - L
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] 1165 - * - - R - - - - - L
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] 1165 - * - - U - - - - - U
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] 1165 - * - - - - - - - - U
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] 1165 R * - - - - - - - - L
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] 1165 invalid lock sequence: 1 Timers
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] full backtrace:
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [11830] device 1 receiver thread ended (pid=1165, tid=11830)
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] /usr/sbin/vdr cStateLock::Lock(cStateKey&, bool, int) calling ?? at ??:0
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr[1165]: invalid lock sequence at Di. 30.06. 09:04
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] /usr/sbin/vdr cTimers::GetTimersRead(cStateKey&, int) calling ?? at ??:0
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] /usr/lib/vdr/plugins/libvdr-skindesigner.so.2.4.2 cGlobalTimers::SetLocalTimers() at ??:?
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] /usr/lib/vdr/plugins/libvdr-skindesigner.so.2.4.2 cGlobalTimers::LoadTimers() at ??:?
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] /usr/lib/vdr/plugins/libvdr-skindesigner.so.2.4.2 cSDDisplayChannel::Flush() at ??:?
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] /usr/sbin/vdr cSkins::Message(eMessageType, char const*, int) calling ?? at ??:0
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] /usr/sbin/vdr cDevice::SwitchChannel(cChannel const*, bool) calling ?? at ??:0
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] /usr/sbin/vdr cDisplayChannel::ProcessKey(eKeys) calling ?? at ??:0
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] /usr/sbin/vdr main calling ?? at ??:0
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] /lib/x86_64-linux-gnu/libc.so.6 __libc_start_main at libc-start.c:342
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] /usr/sbin/vdr _start calling ?? at ??:0
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] --- end invalid lock sequence report
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [1165] --- THERE WILL BE NO FURTHER REPORTS UNTIL VDR IS RESTARTED!
Jun 30 09:04:05 BM2LTSR66Nuc64native vdr: [54288] animator thread thread started (pid=1165, tid=54288, prio=high)
Jun 30 09:04:09 BM2LTSR66Nuc64native vdr: [1165] switching to channel 1 S19.2E-1-1019-10301 (Das Erste HD)
Jun 30 09:04:09 BM2LTSR66Nuc64native vdr: [1165] ERROR: Transfer-Mode kann nicht gestartet werden!
Jun 30 09:04:10 BM2LTSR66Nuc64native vdr: [1165] switching to channel 3 S19.2E-1-1019-10302 (arte HD)
Jun 30 09:04:10 BM2LTSR66Nuc64native vdr: [1165] ERROR: Transfer-Mode kann nicht gestartet werden!
Jun 30 09:04:17 BM2LTSR66Nuc64native vdr: [54288] animator thread thread ended (pid=1165, tid=54288)
Display More
Prima, diesen Fehler habe ich mit meiner Octopus jetzt auch.
Gibt es dazu neue Erkenntnisse?
Leider bekomme ich den Fehler nicht weg ... Kann
invalid lock sequenceetwas damit zu tun haben?
Das sollte in VDR-2.4.4 behoben sein.
Das Problem mit dem Transfer Mode nervt mich wieder heftig. Bald verliere ich noch die Lust am VDR. Hat jemand eine Lösung?
Seid ihr sicher, dass der Fehler überhaupt mit satip zu tun hat?
Seid ihr sicher, dass der Fehler überhaupt mit satip zu tun hat?
Den Transfer-Mode würde ich eher mit dem Ausgabedevice (Plugin) in Verbindung bringen.
(So einen Fehler hatte ich mit einer FFHD6400, rpi3b+ & rpihddevice, diverse ARMPC & softhddevicedrm nicht mehr gehabt...)
Ich kenne diese Meldung auch nicht, nutze aber satip schon lange.
Die Meldung stammt aus device.c Zeile 813.
Um dahin zu gelangen muss SetChannel(...) den Rückgabewert "scrNoTransfer" liefern.
Damit das passiert muss "NeedsTransferMode" "true" werden und etwas beim Umschalten schief gehen.
"NeedsTransferMode" scheint "true" zu sein, wenn das Eingabedevice nicht das Ausgabedevice ist. Sofern man keine FF-Karte hat, also immer bei Live-TV.
IMHO hat also das Umschalten nicht funktioniert.
Interessant sind also die Fehlermeldungen vor "Transfer-Mode kann nicht gestartet werden!"!
Bei mir lag es letztens wahrscheinlich an einem schlechten Kontakt des LAN-Kabels aber dann sah das so aus:
Jan 26 17:59:28 vdr vdr[2885]: [2914] curl_easy_perform() [rtsp.c,244] failed: Timeout was reached (28)
Jan 26 17:59:28 vdr vdr[2885]: [2908] curl_easy_perform() [rtsp.c,244] failed: Timeout was reached (28)
Jan 26 17:59:28 vdr vdr[2885]: [2911] curl_easy_perform() [rtsp.c,244] failed: Timeout was reached (28)
Jan 26 17:59:28 vdr vdr[2885]: [2911] SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.139.201/ [device 2]
Jan 26 17:59:28 vdr vdr[2885]: [2908] SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.139.201/ [device 1]
Jan 26 17:59:28 vdr vdr[2885]: [2914] SATIP-ERROR: Detected invalid status code 0: rtsp://192.168.139.201/ [device 3]
Jan 26 17:59:28 vdr vdr[2885]: [2911] SATIP-ERROR: Connect failed [device 2]
Jan 26 17:59:28 vdr vdr[2885]: [2908] SATIP-ERROR: Connect failed [device 1]
Jan 26 17:59:28 vdr vdr[2885]: [2914] SATIP-ERROR: Connect failed [device 3]
Jan 26 17:59:29 vdr vdr[2885]: [2885] switching to channel 7 S19.2E-133-33-51 (TELE 5)
Jan 26 17:59:29 vdr vdr[2885]: [2885] ERROR: Transfer-Mode kann nicht gestartet werden!
Display More
RKP, hast du Netzwerkfehler?
Hi Wirbel, nicht das ich wüsste, aber ich will es auch nicht ausschliessen. Wie soll man das feststellen? Das sonstige Netzwerk hier läuft problemlos.
Ich vermute mal, dass ifconfig das melden würde.
Danke. Da ist nichts außergewöhnliches zu finden.
Ich habe allerdings jetzt den Octopus mal an einer anderen Stelle im Netzwerk angeschlossen und auch eine andere Koaxialzuleitung ausgewählt. Seit 3 Stunden läuft der VDR jetzt stabil, aber ich muss das über einen längeren Zeitraum testen.
Hat alles nichts gebracht.
Jan 28 21:36:20 ubuntu-yavdr4 epgd: Send 'PLUG epg2vdr STATE standby' to '127.0.0.1:6419'
Jan 28 21:36:20 ubuntu-yavdr4 vdr: [3481] SVDRP ubuntu-yavdr4 < 127.0.0.1:46382 lost connection to client
Jan 28 21:36:20 ubuntu-yavdr4 vdr: [3481] SVDRP ubuntu-yavdr4 < 127.0.0.1:46382 connection closed
Jan 28 21:36:23 ubuntu-yavdr4 vdr: [3459] SATIP: Idle timeout - releasing [device 3]
Jan 28 21:36:44 ubuntu-yavdr4 vdr: [3453] SATIP: Idle timeout - releasing [device 1]
Jan 28 21:36:44 ubuntu-yavdr4 vdr: [3456] SATIP: Idle timeout - releasing [device 2]
Jan 28 21:36:47 ubuntu-yavdr4 vdr: codec/audio: drift( 0) -80655us -38714
Jan 28 21:36:57 ubuntu-yavdr4 vdr: [3448] SATIP: Detected 1 RTP packet error [device 1]
Jan 28 21:36:57 ubuntu-yavdr4 vdr: [3448] SATIP: Detected 1 RTP packet error [device 2]
Jan 28 21:36:57 ubuntu-yavdr4 vdr: [3448] SATIP: Detected 1 RTP packet error [device 3]
Jan 28 21:38:28 ubuntu-yavdr4 vdr: codec/audio: drift( 0) -120377us -57781
Jan 28 21:38:54 ubuntu-yavdr4 vdr: [3459] SATIP: Idle timeout - releasing [device 3]
Jan 28 21:39:15 ubuntu-yavdr4 vdr: [3453] SATIP: Idle timeout - releasing [device 1]
Jan 28 21:39:15 ubuntu-yavdr4 vdr: [3456] SATIP: Idle timeout - releasing [device 2]
Jan 28 21:39:49 ubuntu-yavdr4 vdr: [3454] SATIP-ERROR: failed to send section data (120 bytes) [device=1]
Jan 28 21:39:50 ubuntu-yavdr4 vdr: [3454] SATIP-ERROR: failed to send section data (212 bytes) [device=1]
Jan 28 21:40:08 ubuntu-yavdr4 vdr: message repeated 73 times: [ [3454] SATIP-ERROR: failed to send section data (212 bytes) [device=Jan 28 21:40:08 ubuntu-yavdr4 vdr: codec/audio: drift( 0) -160488us -77034
Jan 28 21:40:08 ubuntu-yavdr4 vdr: [3454] SATIP-ERROR: failed to send section data (212 bytes) [device=1]
Display More
Was hast du den für einen LNB ?
Dieser Fehler im log ist total seltsam.
Jan 28 21:39:49 ubuntu-yavdr4 vdr: [3454] SATIP-ERROR: failed to send section data (120 bytes) [device=1]
Jan 28 21:39:50 ubuntu-yavdr4 vdr: [3454] SATIP-ERROR: failed to send section data (212 bytes) [device=1]
Jan 28 21:40:08 ubuntu-yavdr4 vdr: message repeated 73 times: [ [3454] SATIP-ERROR: failed to send section data (212 bytes) [device=
Die Daten werden wohl zwischen zwei Sockets lokal zwischen Prozessen auf deinem Rechner ausgetauscht, zumindest wurden die sockets mit AF_UNIX erstellt. da würde ich normal keine Probleme erwarten.
Interessant wäre welcher Fehler code dort in void cSatipSectionFilter::Send(void) auftritt, vielleicht kann man ja was draus lernen.
Vielleicht könntest du ja mal dort eine debug Ausgabe einbauen, sectionfilter.c Zeile 215 und folgende.
void cSatipSectionFilter::Send(void)
{
cFrame *section = ringBufferM->Get();
if (section) {
uchar *data = section->Data();
int count = section->Count();
if (data && (count > 0) && (socketM[1] >= 0) && (socketM[0] >= 0)) {
if (send(socketM[1], data, count, MSG_EOR) > 0) {
// Update statistics
AddSectionStatistic(count, 1);
}
-- else if (errno != EAGAIN)
-- error("failed to send section data (%i bytes) [device=%d]", count, deviceIndexM);
++ else if (errno != EAGAIN) {
++ char tmp[256];
++ error("failed to send section data (%i bytes) [device=%d]: %s", count, deviceIndexM,
++ strerror_r(errno, tmp, sizeof(tmp)));
++ }
}
ringBufferM->Drop(section);
}
}
Display More
Ich bekomme auch ab und zu den Fehler, dass er den Transfer-Mode nicht starten kann und habe jetzt zweimal auf verschiedenen VDRs (jeweils mit satip) beobachtet, dass er nach einer Wiedergabe auf den schon vor der Wiedergabe eingestellten Kanal schalten will und dann den Fehler bekommt.
Ob das osdteletext-Plugin, das bei mir im Log auftaucht, da reinspielt kann ich noch nicht sagen. Momentan sieht es für mich so aus, als hätte es nichts mit dem satip-Plugin zu tun, sondern dass cReceiver nicht (vollständig?) abgehängt werden oder sowas in der Richtung.
Habt ihr auch osdteletext installiert?
Don’t have an account yet? Register yourself now and be a part of our community!