yavdr/testing-vdr bekommt ein Update - Rebuild ist durch! (war: wartet also, bis der Rebuild durch ist!)

Nein hat damit gar nichts zu tun. Ich sehe die Aufnahme, die auf dem Server liegt am Client. Währenddessen werden direkt die Schnittmarken angepasst, so dass ich wenn die Folge zuende gesehen ist ich sofort schneide. Dann will ich die nächste Folge öffnen und bekomme die beschriebenen Probleme.
Könnte es sein, dass beim Schneiden die Daten komplett übers Netz hin und her gehen? Denn lokal am Server, tritt das Verhalten nicht auf. Und dass dadurch der VDR irgendwie alle Eingaben blockiert?

remotetimers ist (noch) gar nicht installiert und ist doch nur für die Verwaltung der Timer vom Server gedacht, oder?

Zitat von Torsten73

Könnte es sein, dass beim Schneiden die Daten komplett übers Netz hin und her gehen?

Ja, wenn du nicht extra das Aufnahmemenü von remotetimers nutzt hast du exakt das Problem, dass der lokale VDR sich die Daten vom Server holt und wieder zurückschreibt... extrecmenu ist in der Konstellation also eher hinderlich.

Hallo,

kleine Anmerkung: Bei mir starten folgende Plugins nicht: undelete skinenigmang skinelchi streamdev-server
Meldung: WARNING: The following plugins have been left out due to really binary incompatibility: undelete skinenigmang skinelchi streamdev-server

Aus dem syslog:

grep vdr.*ERROR /var/log/syslog | grep plugin
Mar 19 05:42:55 martini vdr: [26136] ERROR: /usr/lib/vdr/plugins/libvdr-undelete.so.1.7.41: undefined symbol: _ZN10cIndexFile3GetEiPtPlPbPi
Mar 19 05:42:55 martini vdr: [26139] ERROR: /usr/lib/vdr/plugins/libvdr-skinenigmang.so.1.7.41: undefined symbol: _ZN10cIndexFile3GetEiPtPlPbPi
Mar 19 05:42:55 martini vdr: [26158] ERROR: /usr/lib/vdr/plugins/libvdr-skinelchi.so.1.7.41: undefined symbol: _ZN10cIndexFile3GetEiPtPlPbPi
Mar 19 05:42:56 martini vdr: [26178] ERROR: /usr/lib/vdr/plugins/libvdr-streamdev-server.so.1.7.41: undefined symbol: _ZN10cIndexFile3GetEiPtPlPbPi

Ich habe ein Ubuntu 12.04 32bit und verwende die folgenden Quellen:

sudo ls -la /etc/apt/sources.list.d/yavdr-*list
-rw-r--r-- 1 root root 124 Mär 19 05:36 /etc/apt/sources.list.d/yavdr-main-precise.list
-rw-r--r-- 1 root root 138 Mär 19 05:36 /etc/apt/sources.list.d/yavdr-testing-vdr-precise.list
-rw-r--r-- 1 root root 140 Mär 19 05:36 /etc/apt/sources.list.d/yavdr-testing-xbmc-precise.list
-rw-r--r-- 1 root root 142 Mär 19 05:36 /etc/apt/sources.list.d/yavdr-testing-yavdr-precise.list

Ich hatte zeitweise die Unstable-Quellen drin, das war mir aber zu viel
Jetzt bin ich mir nicht sicher, ob ich wirklich "sauber" zurückgestellt habe - vielleicht habe ich da ein Problem. Oder liegt das Problem innerhalb der Repos?

P.S. Ich weiß die yavdr-Repositories und die dahinter steckende Arbeit sehr zu schätzen und freue mich fast täglich darüber

Zitat von mini73

Schau mal nach, was "apt-cache policy vdr-plugin-undelete" usw. sagen, dann weißt du, welche Version woher installiert ist

Das stimmt - das hatte ich ja selber schon geprüft:

sudo apt-cache policy vdr-plugin-skinenigmang
vdr-plugin-skinenigmang:
  Installed: 0.1.2+git20120530-0yavdr11~precise
  Candidate: 0.1.2+git20120530-0yavdr11~precise
  Version table:
 *** 0.1.2+git20120530-0yavdr11~precise 0
        500 http://ppa.launchpad.net/yavdr/testing-vdr/ubuntu/ precise/main i386 Packages
        100 /var/lib/dpkg/status
     0.1.1-7 0
        500 http://de.archive.ubuntu.com/ubuntu/ precise/universe i386 Packages

Das Logfile hilft MIR leider nicht...

P.S. Bitte macht Euch da für mich keine extra-Arbeit. Ich weiß, dass Konstellationen wie meine (32bit-Ubuntu+yavdr-repos) nicht "supported" sind und ich möchte auch nur, wenn möglich, nur ein klein bischen beitragen, wenn ich kann.

Gruß,

Dirk

Nur mal so gefragt: Werden die Neuerungen aus den unstable ppa's nach einer angemessenen Testphase auch in stable ppa's übernommen, oder müssen wir uns bis yavdr 0.6.0 gedulden?

Falk

Zitat von spitzb

Nur mal so gefragt: Werden die Neuerungen aus den unstable ppa's nach einer angemessenen Testphase auch in stable ppa's übernommen, oder müssen wir uns bis yavdr 0.6.0 gedulden?

Das hängt davon ab welches der unstable PPAs du meinst. Pakete aus unstable-yavdr können auch schon mal im Nirvana verschwinden.

Gerald

Zitat von mini73

Kannst du eine VM mit einer frischen Installation aufsetzen, um dann sauber nur die testing-Pakete zu installieren?

Das kann ich gerne probieren - ist halt ein bischen Arbeit. Aber wenn es nicht nur mir was hilft, mach ich es gerne.

Auf die Gefahr hin, dass ich jetzt als totaler Anfänger dastehe, stelle ich mal eine Frage:
Ich habe jetzt eine VM mit ubuntu 12.04 32bit - nakt plus die yavdr-repos.
Dort habe ich dann vdr und ein paar plugins etc. stellvertretend installiert.
Nun fehlt mir /etc/init.d/vdr! dpkg-query -L vdr zeigt es auch nicht an. Wodurch müsste es entstehen?
Danke

Dirk

Zitat von dsteinkopf

Nun fehlt mir /etc/init.d/vdr! dpkg-query -L vdr zeigt es auch nicht an. Wodurch müsste es entstehen?

Das neue VDR-Paket erstellt einen Upstart-Job unter /etc/init/vdr.conf, wenn upstart installiert ist. Unter Ubuntu kann man dann sowas nutzen um den VDR-Daemon zu steuern:

sudo service vdr start|stop|restart

Zitat von seahawk1986

Das neue VDR-Paket erstellt einen Upstart-Job unter /etc/init/vdr.conf, wenn upstart installiert ist.

upstart ist natürlich installiert. (1.5-0ubuntu7.2 aus dem standard-ubuntu-Repo)

Es existiert aber weder ein upstart-Job in /etc/init/vdr.conf noch ein altes Startskript in /etc/init.d/vdr
Demzufolge sagt auch service vdr start nur "vdr: unrecognized service".

Wie gesagt, ich kenne die Situation überhaupt nicht. Weder bei vdr noch sonst wo. Daher komme ich mir ja so anfängerhaft vor...

Zitat von dsteinkopf

Wie gesagt, ich kenne die Situation überhaupt nicht. Weder bei vdr noch sonst wo. Daher komme ich mir ja so anfängerhaft vor...

Bei dem Paket bin ich auch noch Anfänger - ich hab grade reingesehen, der fehlt tatsächlich. Den alten init.d Dienst findest du unter /usr/share/doc/vdr/examples/vdr-init.d - wenn du den nach /etc/init.d/vdr kopierst (und die /etc/default/vdr so anpasst, das der vdr starten darf) sollte es klappen.

Zitat von seahawk1986

Dienst findest du unter /usr/share/doc/vdr/examples/vdr-init.d - wenn du den nach /etc/init.d/vdr kopierst

Genau das habe ich jetzt eh versucht. DAS hat geklappt: vdr startet, nachdem ich noch "sudo chown vdr.vdr /var/lib/video.00" gemacht habe.

Das Ergebnis bezüglich der Ausgangsfrage:

Starting Linux Video Disk Recorder: vdr
Searching for plugins (VDR 1.7.41/1.7.41) (cache miss): xvdr vnsiserver3 xineliboutput
WARNING: The following plugins have been left out due to really binary incompatibility: skinelchi skinenigmang streamdev-server.

Aus dem syslog:

Mar 19 17:36:06 ubuntu-yavdr vdr: [4943] ERROR: /usr/lib/vdr/plugins/libvdr-skinelchi.so.1.7.41: undefined symbol: _ZN10cIndexFile3GetEiPtPlPbPi
Mar 19 17:36:07 ubuntu-yavdr vdr: [4952] ERROR: /usr/lib/vdr/plugins/libvdr-skinenigmang.so.1.7.41: undefined symbol: _ZN10cIndexFile3GetEiPtPlPbPi
Mar 19 17:36:07 ubuntu-yavdr vdr: [4958] ERROR: /usr/lib/vdr/plugins/libvdr-streamdev-server.so.1.7.41: undefined symbol: _ZN10cIndexFile3GetEiPtPlPbPi

Hast du mal versucht eines der betroffenen Plugins lokal neu zu bauen?

sudo apt-get build-dep vdr-plugin-streamdev
apt-get source --build vdr-plugin-streamdev
sudo dpkg -i vdr-plugin-streamdev*.deb

Hab ich grad genau so probiert: Kein Unterschied: streamdev-client läuft (hatte ich vorher nicht drauf). streamdev-server lädt nicht - mit o.g. Meldungen.
(Zur Sicherheit überprüft: Die beiden Files /usr/lib/vdr/plugins/streamdev* sind von heute 18 Uhr und die syslog-Meldung nach restart erscheint genauso wieder.)

Nur zur Sicherheit:

sudo apt-cache policy vdr-dev

Gerald