Beiträge von mw_183

So - gelöst.

Das Problem saß mal wieder zwischen den Ohren: ich hatte das Aufnahmeverzeichnis nicht ganz richtig benannt, statt eines "-" war da ein "." und schon spielt Vdr das nicht mehr ab.

Das Konvertieren funktionierte dann ganz einfach wie immer - bei mir halt am einfachsten mit Avidemux.

Danke nochmal für die Tipps und sorry wegen des falschen Alarms.

Viele Grüße

Matthias

447377

Xcoder

Danke für die Tipps.

Leider kein Erfolg mit allen drei Versuchen, Vdr spielt das Ergebnis nicht ab.

Die müssen in der ARD Mediathek irgendwas komisches mit den Videos machen ... leider kenne ich mich da nicht aus.

Danke & Grüße

Matthias

[Edit] Die Lösung ist im letzten Post: Das Aufnahmeverzeichnis muss schon korrekt benannt sein, sonst klappts nicht ...

Hallo Experten,

mein Vdr hat von "Babylon Berlin" die Folgen 4, 5, 6 nicht aufgezeichnet, da habe ich sie aus der ARD Mediathek runtergeladen und mit Avidemux nach ts gewandelt, so wie ich es vorher schon oft erfolgreich gemacht hatte. Der Vdr (Frontend Softhdd) spielt aber das Ergebnis nicht ab, sondern springt sofort zurück ins laufende Programm. Im Log erscheint keine Meldung.

Hier im Forum habe ich jetzt einige ähnliche Beiträge gesehen und daher auch ffmpeg ausprobiert - hilft bisher nichts.

Hier ist die Ausgabe von ffprobe <originaldatei.mp4>

Und hier die Ausgabe von ffprobe <Ergebnis.ts> für den einfachsten Fall, dass Video und Audio nur kopiert werden

ffmpeg -i Babylon_Berlin-Folge_4-1280-1.mp4 -acodec copy -vcodec copy Babylon_Berlin-Folge_4-1280-1_ffmpeg_copy_copy.ts

Wie man sieht, sind jetzt einige Fehler drin der Art

[h264 @ 0x55f1f46a1720] non-existing SPS 0 referenced in buffering period
[h264 @ 0x55f1f46a1720] SPS unavailable in decode_picture_timing

Das führt wohl auch dazu, dass der Vdr das Ergebnis nicht mehr abspielt. VLC und andere Videoplayer stören sich nicht daran.

Dies ist auch das erste Mal, dass das Wandeln von Mediathek-Dateien in ts für den Vdr nicht funktioniert.

Hier bin ich jetzt ratlos.

Hat jemand einen Tipp?

Danke schonmal

& viele Grüße

Matthias

Hallo,
das klingt hier ja sehr spannend!
Soweit ich sehe, haben alle Tester NVIDIA Grafik benutzt. Wisst ihr, ob dieses softhdd auch mit vaapi läuft, insbesondere ob es für vaapi kompiliert wurde? Habe nämlich ein Asrock j3455.
Danke & Grüße
Matthias

- gelöscht -

Liebe Yavdr-Gemeinde,

hier meine zweite Frage zur Hama MCE: Einige Tastenereignisse werden im vdr nicht wiederholt. Unpraktisch ist das bei der Lautstärke und bei den Zahlen 4 und 6 beim Schneiden. Der USB-Empfänger flackert bei jedem Tastendruck ca. 3 mal auf. Ich meine mal gelesen zu haben, dass das auf ca. 3 gesendete Ereignisse deutet, die dann von einem Repeat-Filter abgefangen werden. Dazu gibt es den langen Thread über die Zeitkonstanten des Repeat-Filters.

Jetzt hätte ich ja gerne die Tastenwiederholung aktiviert statt vermieden. Ist dafür die Zeitkonstante des Repeat-Filters überhaupt eine Option? Muss ich woanders drehen? Oder ist das ganz hoffnungslos?

Danke für Tipps,

Matthias

Liebe Yavdr-Gemeinde,

seit einiger Zeit habe ich jetzt die 0.5a1 auf meinem Test-vdr laufen und sie läuft gut wie noch keine Distri vorher.

Für die 0.5 habe ich mir eine Hama MCE FB besorgt, die auch fast 100% ootb funktioniert. Was mich irritiert ist, dass Play/Pause nicht wie erwartet funktioniert (in vdr, nicht xbmc). Die FB Events sind unter /dev/input/event5 und 6 zu sehen. Bei Druck auf Play oder Pause kommt identischerweise

Event: time 1339936691.711981, type 4 (EV_MSC), code 4 (MSC_SCAN), value c00cd
Event: time 1339936691.711990, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1339936691.711992, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1339936691.712011, -------------- SYN_REPORT ------------

vom Event6. Die Tasten Play und Pause scheinen also das identische Event KEY_PLAYPAUSE zu senden. In /etc/eventlircd.d/hama-mce.evmap wird dieses Event sowohl auf KEY_PLAY als auch auf KEY_PAUSE gemappt:

KEY_PLAYPAUSE   	= KEY_PLAY   # Play (also used for Pause)
 KEY_PLAYPAUSE   	= KEY_PAUSE   # Pause (also used for Play)

Damit kann dann vdr wahrscheinlich nichts anfangen. Gibt es dafür einen Workaround?

Übrigens funktionieren Play und Pause wunderbar mit Up und Down, es wäre halt "nice to have" mit Play und Pause.

Danke für hilfreiche Tipps,
Matthias

Super, bei mir startet xbmc jetzt auch sofort ohne Absturz. Übrigens wurde bei upgrade wirklich nur FF erneuert, bei dist-upgrade dann aber auch u.a. xbmc. Das wird es wohl eher gewesen sein.
Danke für die super Arbeit, damit ist yavdr endgültig die optimale Distro auf meinem Test-vdr.
Gruß, Matthias

Edit: War leider nur von kurzer Dauer, inzwischen wieder zuerst ein Absturz, danach läuft es dann.

Zitat

Wie muß ich denn die Platte formatieren, das die auch unter XP erkannt wird.

Es gibt einen ganz vernünftigen Windows-Treiber für ext2/3, der heißt Ext2IFS. Den findest Du im Netz, und damit kann Windows auf Deine ext3-Partition zugreifen.

Viel Erfolg,
Matthias

Moin drone1563,

ich habe exakt die gleiche Fehlermeldung, seit ich zu dem Toxic-update den Dr. Seltsam-Kernel 2.6.18 installiert habe. Mit 2.6.17.8 gings noch. Daher glaube ich, dass es ein Verständigungsproblem zwischen dem neuen dvb-Treiber für die Nova-t und Femon gibt. Hilft mir aber auch nicht.

Den neuesten Seltsam-Kernel (es gibt eine Version mit gleichem Namen, die aber so ca. 2 Wochen neuer ist als meiner) habe ich noch nicht probiert, dazu komme ich auch frühestens nächste Woche.

Für eine Problemlösung würden genaue Infos über Kernel, vdr, plugins etc. sicher helfen. Ist z.B. Dein System genau wie bei mir zusammengestellt oder anders? Dann können die Experten ran. Ich hätte auch _sehr_ gerne wieder Femon.

Hier noch die Liste der Plugins, die ich lade (femon ist inzwischen raus
dvd dxr3 epgsearch extrecmenu femon skinelchi streamdev-server

Viele Grüße,
Matthias

Moin bochi_01,

folge dem Doktor
Deine lspci-Ausgabe sagt, dass das Modul b2c2_flexcop von dem Modul b2c2_flexcop_pci benutzt wird. Wenn das nicht in Deiner runvdr eingetragen ist, könnte es vielleicht sein, dass dieser Umstand das Entladen von b2c2_flexcop verhindert.

Ich hätte daher vorgeschlagen, in der runvdr _hinter_ b2c2_flexcop zusätzlich b2c2_flexcop_pci einzutragen. Beim Entladen wird die Reihenfolge umgedreht, und b2c2_flexcop_pci würde zuerst entladen, um dann hoffentlich den Weg zum Entladen von b2c2_flexcop freizumachen. Wenn der Doc aber sagt, dass Du nur eins von beiden nehmen sollst, wird er seine Gründe haben.

Viel Erfolg,
Matthias

[edit]
Wieder mal voreilig losgetippt ...
Habe nochmal in Deine runvdr geguckt, die Du letztens gepostet hattest: da sind beide Module drin. Also bleibt nur der Versuch, b2c2_flexcop rauszunehmen und b2c2_flexcop_pci drinzulassen.
[/edit]

Moin bochi_01,

sorry wegen der Verzögerung, ich hatte ein turbulentes Wochenende. Und meine Schlussfolgerungen waren ja wohl auch ziemlich voreilig.

Trotzdem ist mir noch was neues eingefallen: Bei Dir scheint ja das Modul b2c2_flexcop Probleme zu machen. Schau doch mal mit lsmod nach, ob es vielleicht noch von einem weiteren Modul benutzt wird (also z.B. lsmod | grep b2c2_flexcop). Dann könnte man das zuerst entladen.
Du kannst das ja zuerst mal unter 2.6.17.8 probieren, da scheint das Entladen ja auch nicht reibungslos zu klappen.

Viele Grüße,
Matthias

Das sieht doch gar nicht so schlecht aus. Seltsamerweise passiert es auch bei mir manchmal (aber selten), dass "runvdr stop" in einer Endlosschleife hängt, allerdings nur auf der Konsole, beim normalen Runterfahren ist das noch nicht vorgekommen.

Wenn der Aufruf "runvdr stop" in einer Endlosscheife hängt, kannst Du das auf der Konsole mit Strg-C abbrechen. Ein erneuter Aufruf von "runvdr stop" ist bei mir dann immer durchgelaufen.

In den Logs sehe ich nichts Verdächtiges. Lirc scheint beim Starten Schwierigkeiten zu machen. Beim Stoppen kann man sehen, dass vdr planmäßig und erfolgreich beendet wird.

Fazit: es scheint bei Dir jetzt so gut zu laufen wie bei mir. Es kommt jetzt drauf an, ob der vdr beim Ausschalten mit der FB (oder wie Du das sonst machst) sicher runterfährt und zur nächsten Aufnahme wieder rauf.

Viele Grüße,
Matthias

Zeile 99 lautet bei Dir

while [ $NOCHMAL !=0 ]; do

Da fehlt wahrscheinlich ein Leerzeichen:

while [ $NOCHMAL != 0 ]; do

So sieht es jedenfalls bei mir aus, und die Shell ist da oft zickig (bin auch kein echter Experte).

Wenn Du auch noch den Hinweis von oben befolgst und in Zeile 162 in Deiner runvdr das "2>&1 >/dev/null" entfernst, siehst Du auch besser, wo was passiert.

Viele Grüße,
Matthias

[edit]
Du siehst aber schon, dass es im Prinzip funktioniert: immer nach einem FATAL kommt in der nächsten Fehlermeldung eine 1 vor, und das ist der Rückgabewert von modprobe, den wir prüfen wollen.
[/edit]

Zuerst kannst Du nach dem Aufruf von "runvdr stop" (und den FATAL Meldungen) einfach nochmal "runvdr stop" aufrufen, und bei weiteren FATALs nochmal.
Nach dem ersten "runvdr stop" müsste nämlich vdr schon gestoppt sein, nur die Module noch nicht entladen. Das siehst du z.B. wenn bei "ps aux | grep vdr" nichts kommt. Wenn Du dann nach ein paar Sekunden nochmal "runvdr stop" versuchst, müssten sich die Module entladen lassen, also kein FATAL.

Um die paar Sekunden Wartezeit zwischen dem Beenden von vdr und dem Entladen der Module fest einzubauen, gibt es zwei Wege:
1. In der runvdr trägst Du im Abschnitt "down)" direkt vor dem Aufruf von "unloaddriver" ein "sleep 10" (oder mit einer anderen Zahl) ein.
2. In der runvdr trägst Du in der Funktion "unloaddriver()" die Warteschleife aus meinem Beitrag von der Vorseite ein. Vielleicht ist dort auch "sleep 2" statt "sleep 1" besser, um noch behutsamer vorzugehen.

Viel Erfolg,
Matthias

Moin bochi_01,

das _könnte_ mit dem Entladen von Modulen zu tun haben, wie es manchmal vorkommt.

Versuch mal folgendes: in der Datei /etc/init.d/runvdr im Abschnitt "stop)" lautet die erste Zeile

/etc/init.d/runvdr down 2>&1 >/dev/null

Das änderst Du in

/etc/init.d/runvdr down

So bekommst Du die Ausgaben von modprobe beim Entladen der Module zu sehen.

Wenn Du jetzt auf der Konsole "/etc/init.d/runvdr stop" aufrufst und es kommen Meldungen wie "FATAL: module xxx is in use", dann hast Du das Problem gefunden. Lösung siehe oben in diesem Thread oder ich beschreibs Dir dann nochmal.

Wenn das nicht kommt, ist es irgendein anderes Problem. Dann musst du im setup das "Ringbuffer Syslog ausschalten" und zusätzlich den Link
"/var/log -> /ramdisk" löschen UND das Verzeichnis /var/log neu anlegen, damit Du das syslog von vor dem Absturz hinterher noch sehen (und dann auch posten) kannst.

Viel Erfolg,
Matthias

Hej herrdeh,

wenns wieder mal Oopsen sollte, kannst Du ja mal Das Hier ausprobieren (ganz unten).

Funktioniert bei mir besser als feste Zeiten, weil die nötige Wartezeit stark schwankt.

Viele Grüße,
Matthias

Hallo Doc,

Zitat

Ein längerer Auszug aus /var/log/messages könnte vielleicht noch helfen.

Ist angehängt. Die Startphase kommt mir ok vor.

Zitat

Welche femon-Version ist es denn?

Da ich das Toxic-Update 1.4.2-3 habe, ist es die 1.1.0 (siehe auch angehängtes log).

Zitat

Ich vermute, dann ist ausschlaggebend, welche Karte zuerst geladen wird.

Das ist in der Tat so. Ich meinte was anderes: Wenn ich live-TV gucke, und es startet eine programmierte Aufnahme, so hat vdr (1.3.17) sich die 1. Karte für die Aufnahme geschnappt, und das live-TV wurd auf die zweite Karte umgeschaltet. Das war an eine kurzen Unterbrechung im live-Bild zu merken. Jetzt scheint vdr (1.4.2) die Aufnahme auf der 2. Karte zu starten, so dass ich als TV-Gucker das gar nicht merke. Oder hab ich mir das verkehrt zusammengereimt?
Jedenfalls hat meine alte Nova-t schlechteren Empfang als die neue. Wenn jetzt praktisch alle Aufnahmen von der alten gemacht werden, könnte das ein Nachteil sein. Dann würde ich wohl die Reihenfolge wieder zurücktauschen, so dass ich auf der alten gucke und mit der neuen aufnehme.

Zitat

Dein script werde ich mal ausprobieren.

Viel Vergnügen. Die echos kriegst Du natürlich nur zu sehen, wenn unloaddriver ohne das ">/dev/null" am Ende der Zeile aufgerufen wird.

Zitat

hast Du mein upgedatetes Paket vom 15.10. schon probiert?

Nein, noch nicht. Ich bin im Moment etwas ängstlich mit Updates, weil die Familie immer stärker den vdr für sich beansprucht, und dann muss er funtionieren Vielleicht komme ich erst nächste Woche dazu.
Das neueste Toxic-Update hab ich ja auch noch nicht. Wüsste gerne, ob und wie es inzwischen mit der dxr3 läuft.

Viele Grüße & vielen Dank für die Hilfestellungen
Matthias

Moin nochmal,

vor einer guten Woche hatte ich hier von Problemen mit dem 2.6.18 berichtet. Seitdem habe ich ein paar Logs und andere Ausgaben gesammelt. Inzwischen läuft bei mir der 2.6.18, scheint auch stabil zu sein. Folgendes beobachte ich:

- femon zeigt weiterhin im OSD nichts an. Daher hab ich es erstmal deaktiviert. Im Log erscheint eine Fehlermeldung (siehe Dateianhang).

- drücke ich bei live-TV "OK", so erscheint die übliche OSD-Anzeige, aber ohne EPG-Infos. Bei Kanalwechsel sind die EPG-Infos sofort da.
Das war beim 2.6.17.8 schon genauso, dort erschienen die EPG-Infos allerdings kurz bevor das OSD von selbst wieder verschwand. Es scheint also nur die Verzögerung größer geworden zu sein. Im Log erscheint dazu nichts.

- vdr Absturz konnte ich nicht reproduzieren bis jetzt. Vielleicht lag es an femon? Oder an schlechtem Empfang? Ich habe den Verdacht, dass vdr 1.4.x die DVB-Karten in einer anderen Reihenfolge benutzt als 1.3.17, wenn zusätzlich zum live-TV eine Aufnahme startet. Meine Zweitkarte Nova-t 928 empfängt nicht immer so gut. Daher hatte ich die andere Nova-t 90002 als Erstkarte eingerichtet.

Folgende Logs etc. hänge ich (im tgz) an:

dmesg_2.6.17.8 Boot-Meldungen des 2.6.17.8
dmesg_2.6.18 Boot-Meldungen des 2.6.18
interrupts_2.6.17.8 /proc/interrupts unter 2.6.17.8
interrupts_2.6.18 /proc/interrupts unter 2.6.18
lspci-v_2.6.17.8 Ausgabe von lspci -v unter 2.6.17.8
lspci-v_2.6.18 Ausgabe von lspci -v unter 2.6.18
messages_2.6.18_femon Schnipsel aus /var/log/messages mit femon-Fehlermeldung

Den einzigen auffallenden Unterschied sehe ich bei den Meldungen der cx88_* Module: beim 2.6.18 kommen da deutlich mehr Ausgaben.

Aktive Plugins:
dvd dxr3 epgsearch extrecmenu femon skinelchi streamdev-server

Weiß jemand, wie ich femon wieder zum Laufen kriege?
Und wie ich bei live-TV mit "OK" auch EPG-Infos zu sehen kriege?

Ansonsten scheint der 2.6.18 zufriedenstellend und stabil zu laufen.

Vielen Dank fürs Mitlesen, und natürlich für die ganzen prima Kernel,
Matthias

Nachsatz:
Viele Probleme hatte ich in letzter Zeit mit Modulen, die vor dem Entladen längere Bedenkzeit brauchen. Welche sleep-Zeiten ich auch immer in die runvdr einfügte, irgendwann gab es beim Runterfahren eine Kernel Panic oder Oops.

Jetzt habe ich die ganzen sleeps rausgeworfen und prüfe beim Entladen den Rückgabewert von modprobe (Schnipsel aus runvdr, Abschnitt "unloaddriver)"):

for module in $MODULES; do
    if [ -n "${module##\#*}" ]; then
      grep -w "^${module%% *}" /proc/modules >/dev/null 2>/dev/null
      if [ "$?" == "0" ]; then
        #sleep 1
        echo "entlade Modul ${module%% *}"
        modprobe -r ${module%% *}
	NOCHMAL=$PIPESTATUS
	echo "NOCHMAL ist $NOCHMAL"
	while [ $NOCHMAL != 0 ]; do
		echo "    nochmal ..."
		sleep 1;
	        modprobe -r ${module%% *};
		NOCHMAL=$PIPESTATUS
	done
        echo "... Modul ${module%% *} entladen"
      fi
    fi
  done

Die ganzen echos sind natürlich nur zur Info.
Seitdem ist er stets sauber runtergefahren, mit Wartezeiten so zwischen 4 und 10 Sekunden, wenn ich gerade an der Konsole saß. Vielleicht ist das ja eine Anregung für andere Geplagte.

Moin,

der neue Kernel funktioniert bei mir leider nicht "out of the box" wie die vorigen. Folgende Probleme tauchten auf:

1. femon über Fernbedienung aktiviert: auf dem TV erscheint nichts. Im Log steht etwas wie "femon error: could not open dvb device for OSD" (nur diese eine Zeile). "OK" drücken auf der Fernbedienung: keine Reaktion auf dem TV.

2. Nach ca. 3-5 Minuten startet vdr neu - scheinbar grundlos. Im Log konnte ich nichts hilfreiches dazu sehen.

3. Beim Runterfahren ab und zu wieder Kernel Panic, obwohl ich inzwischen ziemlich viele "sleeps" in die runvdr eingetragen habe.

Das alles führte dazu, dass ich schnell wieder den alten 2.6.17.8 aktiviert habe, denn es stand eine wichtige Aufnahme an. Der Kernel Panic Fehler blieb aber bestehen (!). Inzwischen habe ich das ganze linvdr-kernel-2.6.17.8.tgz nochmal darüber ausgepackt, und der Fehler scheint fürs Erste beseitigt zu sein.

Leider sind keine Logs von diesem kurzen Versuch erhalten. Ausführlich kann ich erst wieder am Wochenende testen, daher ist dies nur eine erste Rückmeldung.

Trotz allem natürlich vielen Dank für die immer superaktuellen Kernel, die auch meistens super laufen!

Viele Grüße,
Matthias

[edit]
aktivierte Plugins waren:
dxr3, epgsearch, extrecmenu, femon
[/edit]