finally vdr-1.2.0.ebuild is online

Hi mad

Ich bin sprachlos. Wie findest du nur die Zeit dafür. Das geht ja rasant. Ich komme nicht mal zum Testen. Das hat aber einen anderen Grund (Server-Umbau auf Linux). Ich hoffe, daß ich sobald wie möglich dazukommen werden. Bedanke mich wie immer schon mal dafür

Martini

hiho

dadrauf habe ich gewartet ...

werde das gleich nachher mal testen.

muss dann nur die plugins per hand nach ziehen oder? du sagtest das du nicht weist ob du die plugins noch schaffst... das heist bis jetzt gib es nur den nackten vdr!?

machst du das alles alleine? .. kann man da helfen? wollt ihr hilfe? wollt ihr keine? was kann man helfen wenn man kann.

gruesse

werde mir das mal angucken .. durchlesen .. versuchen zuverstehen.. testen .. und bescheidgeben

thx

Hi,

mad
sieht ja gut aus das neue ebuild. Die vdr_opts Variante gefällt mir auch viieel besser als die USE Geschichte.
Nur leider komme ich wohl vor dem Wochenende weder zum Test noch zur Installation.

Den patch werde ich dann natürlich auch unter die Lupe nehmen, denn ohne AC3 geht bei mir inzwischen nichts mehr.
Wenn du ein passendes ebuild für ein plugin bis dahin fertig hast, werde ich mal schaun ob ich dann auch ein paar gestrickt bekomme. Sollte ja nicht sooo schwer sein.
Fang doch mal mit was leichtem an. Clock z.B.

Gruß Henning

Hi Mad,

Zitat

Original von mad
Was mir noch fehlt für das Paket:
- sudo eintrag für shutdown script (kenn mich mit sudo nicht aus)

Der Chef darin bin ich zwar auch nicht, aber ich will es mal versuchen.
Einträge werden in /etc/sudoers gemacht - klar. (man sudoers)
Normalerweise über visudo. Ruft vi oder einen anderen Standardeditor auf. Neben Checks soll das verhindern, dass das sudoers-File gleichzeitig von mehreren usern editiert wird. Denke mal, dass das Problem bei einer Installation von vdr in 99,9999 Prozent aller Fälle theoretischer Natur ist;-). Andernfalls müsste man das scripten.

simpler Eintrag für vdr (host name mit dem output von "hostname -a" oder "hostname" ersetzen. Verwendung eines fqdn scheint aber nicht üblich zu sein:
# Schema: user(s), host(s) = NOPASSWD: command(s)
vdr hostname = NOPASSWD: /pfad/zu/vdrshutdown.sh
oder bei mehreren Kommandos auch:
vdr hostname = NOPASSWD: /pfad/zu/vdrshutdown.sh, /pfad/zu/sonstwas.sh

universeller:
Host_Alias LOCAL = hostname
User_Alias VDR = vdr
Cmnd_Alias VDR_CMNDS = /usr/local/bin/vdrshutdown, /usr/local/bin/vdrsonstwas
VDR LOCAL=NOPASSWD: VDR_CMNDS

Zitat

- watchdog von metrio ?? per Mail vielleicht

Sollten wir noch etwas zurückstellen: vor ein paar Tagen hatte ich einen Fall, dass der vdr was am aufnehmen war, offenbar nicht richtig tunen konnte, und sich beendet hat. Der watchdog war angesprungen, hat die Treiber entladen, vdr neu gestartet, und das selbe Spiel von vorn. Nachdem sich das ca. 15 Mal wiederholt hatte, ist der Watchdog plötzlich abgeschmiert. Zwei Dinge:
- Ich weiß nicht, was da los war - ob es am Sender lag oder daran, dass die Treiber nicht sauber entladen wurden.
- Habe eben nochmals getestet: Wenn ich den vdr ca. 15 Mal kille, dann stürtzt der Watchdog ab. Speichermäßig konnte ich nichts besonderes beobachten.
Wenn ich den vdr über die Konsole starte, dann wird er offenbar nicht "anständig" in den Hintergrund geschickt (so wie das start-stop-daemon macht). Kann man gut nachvollziehen, indem man sich per ssh einloggt, /etc/init.d/vdr star eingibt, und sich dann wieder ausloggt - dann bleibt man hängen. Daher brauche ich ja diesen workarount mit popen statt command.getstatusoutput. Vielleicht liegt hier ja der Hund begraben. Du hast nicht zufällig ne Idee, wie du das im Startscript zurechtbiegen könntest?

Werde jetzt mal den ebuild installieren und mich melden, wenn's was Neues gibt.

Hm - heute Morgen ist mein vdr übrigens nicht anständig hochgefahren. Diverse logfiles ganz massiv mit "ring buffer overflow" o.ä. zugemüllt. Tausende von Einträgen pro sekunde. Innerhalb von ein paar Minuten waren 3 x 170MB zu und die rootpartition vollgelaufen. Die betreffende Aufnahme war ok - zumindest *nachdem* die Partition vollgelaufen war. Den Teil davor hatte ich schon weggeschnitten, beim Schneiden war mir nix besondere aufgefallen.

grüße

metrio

Hi Mad

Zitat

Original von mad
leider funzt das start-stop-daemon mit dem vdr nicht da die Übergabeparameter für die Plugins so scheisse sind. Daher vdr --daemon und der sollte sich eingendlich sauber in den Hintergrund verabschieden.

Klar - das mit den Übergabeparametern hattest du ja schon mal erwähnt. Er geht in den Hintergrund, aber eben nicht 100pro sauber.

Zitat

sudo ist geklärt. kommt nicht mit ins ebuild muss jeder selber einrichten? evt nen hint in die vdrshutdown.sh

Hatte ich glaube ich auch schon mal angesprochen: das shutdown-script muss eh jeder selbst in Betrieb nehmen - bei der Gelegenheitkann man sich auch um den suso-Eintrag kümmern.

Mit dem Watchdog bin ich gerade noch am rumspielen. Nur dumm, dass das ne ganze Weile dauert, bis der Fehler kommt. Sollte mir auch so langsam überlegen, Gewitterpause zu machen...

grüße

metrio

Hi,

hab mir gerade einen neuen Kernel gebacken, die DVB Treiber (pre3) gebaut. So weit ok.
Beim emerge vdr hagelt es dann aber Fehlermeldungen, wegen des fehlenden Users vdr.

mad
Ich denke da solltest du noch mal drauf schauen.

Henning

Hi Mad,

Zitat

Original von metrio
Er geht in den Hintergrund, aber eben nicht 100pro sauber.

Muss mich revidieren. Habe alle ebuilds eingespielt - funzt prima, bis auf... s.u.
Das Startscript *geht* sauber in den Hintergrund, und ich habe den Watchdog entsprechend modifiziert. Allerdings gibt es immer noch Probleme. Hoffe, dass ich das noch in den Griff kriege. Laden tut der vdr die Treiber automatisch, oder? Aber wie soll ich die Treiber am besten entladen?

Probleme mit den ebuilds gibt's bei mir mit der zweiten Karte. Also wenn ich die Treiber manuell, bzw. mit dem alten Script entlade, und dann den vdr starte, dann erkennt er nur eine von zwei Karten. Die zweite Karte ist eine nova.
Entlade ich die Treiber wieder manuell und lade sie manuell, um dann den vdr neu zu starten, dann ist alles ok.

Wenn der vdr nur 1 device hat, dann sehe ich unter /dev/dvb/adapter1:
demux0 dvr0 net0

bei zwei devices kommt noch frontend0 hinzu:
demux0 dvr0 frontend0 net0
Vielleicht sagt dir das ja schon was.

grüße

metrio

Zitat

Original von mad
@metrino: leider hab ich so nen karte nicht und weiss nicht welche module noch zusätzlich oder mit extra opts geladen werden. Kannste das evt. in der /etc/modules.d/linuxtv-dvb geradebiegen? Ich hab in dvb startscript auch nix anderes gemacht als so ein paar module zu laden , was ich bei mir feststelle ist das endev und videodev nicht geladen sind! DIe hab ich vorher im dvb-rc-script geladen??!?

evdev ist bei mir jetzt auch nicht geladen, videodev im Gegensatz dazu schon:
videodev 6368 1 (autoclean) [dvb-ttpci]

Gefehlt für die nova stv0299, was auf für dieses frontend0 verantwortlich ist. Habe es ganz hinten in linuxtv-dvb angefügt.
Ist "unused", nur wenn man es entlädt steigt der vdr irgendwann aus.

Zitat

das entladen der dvb treiber bau ich ins rc vdr script ein. Hoffe das passt da rein (logisch, nicht vom Speicherplatz ;-)) )

Klingt ok - falls da nicht unter irgendwelchen Szenarien auch andere, laufende Programme drauf zugreifen müssen. k.A.

Mist - diesen Ringbuffer-overflow habe ich heute nochmals gehabt. Scheint im vdr zu passieren:
vdr[7075]: ERROR: ring buffer overflow (188 bytes dropped)

Bin gerade am syslog-ng am schrauben. Alles vdr-spezifische kommt erst mal in ein File. Diese ringbuffer-geschichte filtere ich vorläufigl aus. Und die svdrp-meldungen (durch den watchdog) kommen auch in ein separates File oder werden ebenfalls ausgefiltert.

grüße

metrio

Hi,

hab bislang 2 Probleme mit der neuen Version festgestellt.

1.
VDR erkennt nur das erste DVB device (Siemens 1.3). Die Zweite Karte (Technisat SkyStar 1.6) bleibt ungenutzt, es sei denn, ich lade die Treiber wie gehabt über /et c/init.d/dvb start

2.
Wenn ich vdr über das init script starte, also mit daemon, gibts ein Problem mit mplayer.
Nach Auswahl eines mpeg files, sieht man nichts, bzw. das Fernsehprogramm läuft weiter.
Man kann jedoch 'Wiedergabe beenden' auswählen. Anschließend läßt sich vdr aber nicht mehr bedienen. Ursache hiefür scheint ein hängender mplayer Prozess zu sein. Wird der gekillt, geht auch vdr wieder.
Bei Aufruf direkt aus der Shell heraus, und ohne --daemon läuft mplayer.

Gruß Henning

Hi Henning

Zitat

Original von Henning
hab bislang 2 Probleme mit der neuen Version festgestellt.

1.
VDR erkennt nur das erste DVB device (Siemens 1.3). Die Zweite Karte (Technisat SkyStar 1.6) bleibt ungenutzt, es sei denn, ich lade die Treiber wie gehabt über /et c/init.d/dvb start

Ist das nicht praktisch das gleiche Problem, das ich hatte? Also Module mit/ohne zweite Karte vergleichen und fehlendes Modul in /etc/modules.d/linuxtv-dvb anhängen und dann update-modules? Und natürlich hier posten, damit Mad es aufnehmen kann;-).

Zitat

2.
Wenn ich vdr über das init script starte, also mit daemon, gibts ein Problem mit mplayer.
Nach Auswahl eines mpeg files, sieht man nichts, bzw. das Fernsehprogramm läuft weiter.
Man kann jedoch 'Wiedergabe beenden' auswählen. Anschließend läßt sich vdr aber nicht mehr bedienen. Ursache hiefür scheint ein hängender mplayer Prozess zu sein. Wird der gekillt, geht auch vdr wieder.
Bei Aufruf direkt aus der Shell heraus, und ohne --daemon läuft mplayer.

Alles anzeigen

Mit "direkt aus der Shell heraus" meinst du, vdr mit sämtlichen Parametern von Hand aufrufen?
Da fällt mir auch nix weiter zu ein. Rechte? Habe das plugin gestern installiert, und alles scheint zu klappen - zumindest mit mplayer.sh. Du könntest ja mal die betreffenden config-files posten.

BTW - ich weiß nicht, ob es allgemein hier bekannt ist: Zur Vermeidung etwaiger sync-Probleme mit mplayer kann man folgendes in /etc/conf.d/local.start hinten anhängen:
echo 1024 > /proc/sys/dev/rtc/max-user-freq

Grüße

metrio

Hi,

hätte gern etwas Nachhilfe, zum laden der Treiber
Hier erst mal der funktionierende Aufruf:
/sbin/modprobe videodev
/sbin/modprobe dvb-core dvb_shutdown_timeout=0
/sbin/modprobe alps_bsrv2
/sbin/modprobe alps_tdmb7
/sbin/modprobe alps_tdlb7
/sbin/modprobe grundig_29504-401
/sbin/modprobe grundig_29504-491
/sbin/modprobe stv0299
/sbin/modprobe ves1820
/sbin/modprobe evdev
/sbin/modprobe input
/sbin/modprobe dvb-ttpci hw_sections=0

Dann noch die /etc/modules.d/linuxtv-dvb, die ja nicht funktioniert
probeall /dev/dvb dvb-ttpci
alias /dev/dvb/* /dev/dvb
below dvb-ttpci alps_bsrv2 grundig_29504-401
add below dvb-ttpci grundig_29504-491 ves1820 alps_tdmb7 alps_tdlb7

Da ich keinen Plan habe, was 'add, below, alias, probeall' bewirken, weiß ich nicht, was nun wo ergänzt werden müßte.
Augenscheinlich fehlen erst einmal stv0299, evdev, input.
Wie kommen denn nun noch die Parameter zu dem gewünschten modul ???
Im übrigen fehlt unter /dev/dvb/adapter1 nur frontend0 gegenüber adapter0.

Gruß Henning

Hi Henning,

Die Dateien in /etc/modules.d werden zu einer modules.conf zusammengeschustert, daher
"man modules.conf".

Wenn ich das halbwegs richtig verstanden habe:
Durch einen Zugriff auf /dev/dvb* wird dvd-ttpci geladen, und wenn das geladen werden soll, dann werden vorher noch die module, die hinter, ["add] below dvd-ttpci modulname1... modulnamen " spezifiziert sind, geprobed, bzw. geladen.

mache in beiden Zuständen (vdr erkennt nur 1 Karte, vdr erkennt beide karten) ein lsmod, und vergleiche die Module, die jeweils geladen sind. Die Modulnamen, die bei der 2er Version zusätzlich geladen sind, kannst in einer Zeile der Form

add below dvb-ttpci modulname-1 modulname-n

.... verewigen.

Sollte imo auch reichen, alle modulnamen, die mad nicht aufgeführt hat, die aber in deinem funktionierenden Aufruf vorkommen, in dieser Art aufzuführen.

die Zeilen für die Optionen sehen so aus::

options dvb-core dvb_shutdown_timeout=0
options dvb-ttpci hw_sections=0

Und update-modules nicht vergessen;-).

grüße

metrio