Posts by wmautner

Uhm. Kodi ist auf Android9 für mich nicht brauchbar: es gibt keinen BACK- und HOME-Button mehr.

Daß ein TAB der ddbridge mal nicht erkannt wurde, hatte ich auch schon. Es half in dem Fall immer nur, den VDR komplett runterzufahren (stromlos, Reboot reichte nicht) und dann erst neuzustarten.

Mit den nun im Kernel integrierten Treibern (auf die Xenial-Kernels 4.15 umsteigen) klappt es eigentlich immer problemlos, kein media-build-experimental mehr notwendig.

VDRManager in Verbindung mit VLC (für Smartphones) ist zu empfehlen, mit Streamdev-Server am VDR natürlich. Man kann auch Remux (externremux.sh) konfigurieren für schmale Bandbreite.

Ich hab da noch vdrnfofs als Möglichkeit, Aufnahmeverzeichnisse inklusive Datum/Zeit und Titel zu "exportieren":

mkdir -p /srv/vdr/vdrnfofs && vdrnfofs /srv/vdr/vdrnfofs -o video=/srv/vdr/video,allow_other

und das dann per samba exportieren:

(als /etc/samba/smb.conf.yavdr.custom etc. includen)

sieht dann etwa so aus:

Für Programmierer läßt sich sicher das Python-Script "/usr/bin/vdrnfofs" so anpassen, daß das Datum zuerst angezeigt wird.

Das exportierte Verzeichnis kann von Kodi gut verarbeitet werden.

Aber Achtung: die Geschwindigkeit ist nicht gerade berauschend.

Ich weiß nicht, ob Ihr das meint, aber ich habe in /etc/modprobe.d sowas drin:

options ddbridge adapter_nr=0,1,2,3 msi=0

# damit werden die DVB-S auf "TAB0" immer als Tuner 1 und 2,

die DVB-C auf "TAB1" als Tuner 3 und 4

options dvb_core dvb_powerdown_on_sleep=0

options budget_ci adapter_nr=4

und die noch dazu vorhandene TT3200 als Tuner 5 eingebunden.

options stv0367 i2c_debug=0

# debug war nur wegen des Ärgerns, da, jedes 10.x hängt i2c_write auch und ich muß komplett kaltstarten um die dvb-C tuner wieder zu kriegen.

options budget_core bufsize=1024

~

~

Hat soeben hier (Ubuntu-14.04.5 KDE, und auch am yavdr-0.6 selbst) anstandslos funktioniert mit wget.

Vielleicht ist irgendwas in der wgetrc b0rken?

Enthalten nicht Kernel ab 4.14 bereits die entspr. Module? Ist das ein voll selbstkonfigurierter und -kompilierter Kernel?

Nein, denn "agpgart" ist nur für alte Grafikkarten relevant.

Aber mal eine ganz blöde Frage: den Eintrag in /etc/group für "video" gibt es aber schon, und der vdr-User ist Mitglied?

Ich habe da in /lib/udev/rules.d/50-udev-default.rules

SUBSYSTEM=="video4linux", GROUP="video"

SUBSYSTEM=="misc", KERNEL=="agpgart", GROUP="video"

SUBSYSTEM=="graphics", GROUP="video"

SUBSYSTEM=="drm", GROUP="video"

SUBSYSTEM=="dvb", GROUP="video"

stehen bei yavdr.

In /etc/udev/rules.d ist keine Gruppe video spezifiziert.

Klingt als müßten Sie mal die Karte einschicken und testen lassen ...

Nur zur Sicherheit: Floppy-Kabel (Stromversorgung) angesteckt?

Den Parameter "msi=0" an das ddbridge-Modul übergeben?

(Datei ddbridge.conf in /etc/modprobe.d mit Inhalt "options ddbridge msi=0")

Funktioniert epgd auch? Was sagt "status mysql", epgd-showmerge und epgd-tool -show-stats?

Eigentlich initialisiert der epgd-Dienst beim Starten das mysql, und das sollte dann durchlaufen ...

wwwork wrote:

Was ist "table rc-tt-1500" für ein Protokoll? Davon habe ich zuvor nie etwas gelesen.

Das ist die Übersetzungsdatei, das Protokoll "rc-5" steht ganz oben.

wwwork wrote:

wwwork wrote:

Hallo wmautner,

was genau macht "head /lib/udev/rc_keymaps/rc-tt-1500", diesen Befehlt kannt ich zuvor nicht.

"head" zeigt einfach die ersten Zeilen einer Datei an.

Ich wollte nur das "rc-5" zeigen.

Kann man sagen die TechnoTrend Budget S2-3200 ist bezüglich ir-Remote Support spärlich ausgestattet?

Meine läuft auch mit der mitgelieferten FB (die Tastenbeschriftungen sind nicht mehr existent, sonst funktioniert sie aber) und dem IR-Empfänger.

Ich hab auch eine silberne FB einer Hauppauge-Karte, mit der tut sich der Empfänger schwer: einige Tasten kennt er, die meisten nicht.

Ist halt immer eine Frage der Frequenzen etc.

Display More

wwwork wrote:

MfG

wwwork

# head /lib/udev/rc_keymaps/rc-tt-1500

# table rc-tt-1500 type: rc-5

0x1501 KEY_POWER2

0x1522 KEY_EPG

0x1512 KEY_INFO

0x150d KEY_UP

0x1511 KEY_DOWN

0x150e KEY_LEFT

0x1510 KEY_RIGHT

0x150f KEY_OK

0x1513 KEY_ESC

Wobei der Code nichts zu den verwendeten Frequenzen sagt.

Wie gut S3 mit welchen Kernels funktioniert, hängt natürlich auch vom Mainboard, zusätzlichen Karten und der Wetterlage ab

Ich hab 4.15.0-23, S3 tut auf einem ausgemusterten Xeon-"Server", aber beim Aufachen will die TT S2-3200 meist nicht mehr (negativer Modul-Count bei einem Modul, das sich dann nicht mehr laden läßt). S5 kann die Kiste überhaupt nicht bzw. da wacht sie nicht mehr auf.

Drum lass' ich sie im S3 und habe das zuerst beim Wakeup ausgeführte Script in /etc/pm/sleep.d mit einem frühen "reboot" verziert. Naja, nicht ideal,

aber tut so.

Diese Treiber sind doch in den neueren Kernels "extra" und müssen nicht geladen werden. Einfach linux-midules-extra-*kernel*-generic deinstallieren oder nicht installieren, sollte auch helfen?

Hmm. Bei mir kommt nach "CPU..." die dmesg-Meldung über ACPI-S3 Wakeup und dann USB:

Jun 8 07:11:40 hdvdr kernel: [32792.560230] CPU3 is up

Jun 8 07:11:40 hdvdr kernel: [32792.562841] ACPI: Waking up from system sleep state S3

Jun 8 07:11:40 hdvdr kernel: [32792.602433] usb usb3: root hub lost power or was reset

Jun 8 07:11:40 hdvdr kernel: [32792.602442] usb usb4: root hub lost power or was reset

Ich würde mal eventuell verbundene externe USB-Geräte abhängen, wenn möglich ...

Wie sieht dmesg bei Version 0.5 aus?

don-baba wrote:

Also anstatt ein Video1,2,3,... einzubinden kann man auch einfach die neue Platte (mit den richtigen Userrechten) als Unterordner in video0 einbinden und diese Platte als Archiv nutzen und alle paar Tage die Aufnahmen auf die Archivplatte verschieben.

Ja, das habe ich sogar mit dem 2. Teil der 2GB-Platte noch gemacht, die als "scifi"-Unterverzeichnis (halt ohne Raid-Sicherhiet) eingehängt

LABEL="DATEN" /srv/vdr xfs logbufs=8,logbsize=256k,largeio,attr2,filestreams,relatime,nodiratime,nodev 0 0

LABEL="SCIFI" /srv/vdr/video/scifi xfs logbufs=8,logbsize=256k,largeio,attr2,filestreams,relatime,nodiratime,nodev 0 0

Hier mein Raid-Setup:

# blkid /dev/md126

/dev/md126: LABEL="DATEN" UUID="814fc9d9-50f8-4f36-8d75-5b3458d40051" TYPE="xfs"

# cat /proc/mdstat

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]

md126 : active raid5 sdb2[7] sde3[2] sdf3[5] sdc3[4] sdd3[6]

3822534656 blocks super 1.2 level 5, 256k chunk, algorithm 2 [5/5] [UUUUU]

aus /etc/fstab:

LABEL="DATEN" /srv/vdr xfs logbufs=8,logbsize=256k,largeio,attr2,filestreams,relatime,nodiratime,nodev 0 0

Es kann auch nicht schaden, ein "bootdegraded" in /etc/default/grub (Achtung, templated) anzuhängen (CMDLINE_LINUX_DEFAULT) und

update-grub durchzuführen.

Bei Raid5 (ich hab alle 5 aktiv) darf (nur) eine Platte ausfallen, das ist ja der Sinn des Raid5. Egal, wieviele Platten im Array sind.

Die muß dann natürlich rasch ersetzt werden, denn der Teufel schläft nicht

Eine "Spare"-Platte läuft halt auch immer mit, zumindest die Elektronik - auch wenn sie bei Nichtbenützung in den Stromsparmodus geht.

Z.B. wird sie für die regelmäßigen smartd-Läufe immer wieder mal geweckt, beim Runter- und Hochfahren auch ...

Und natürlich kann man ein SW-Raid5, solang noch Anschlüsse verfügbar sind, jederzeit erweitern.