VdrAssistant (Pes, Pes-HD, TS und TS-HD Aufnahmen verwalten und "offline" konvertieren)

Zitat

Ich hab den Assistenten neu installiert. Außerdem hab ich meine Locale umgestellt auf de_DE (iso-8859-1). Das ist die Codierung der Platte des Servers und so werden endlich alle Aufnahmen beim Scan erfasst.

Hm, also beim Installieren kann man den Zeichensatz des VDR angeben (Vorgabe ist Iso-8859-1) und damit klappt es bei mir.

Würde mich interessieren, was der Scan nicht erfassen konnte ...

Zitat

Ich hab mich einfach mal nicht mehr um Themes und Skins gekümmert sondern sofort einen Job erstellt mit Standard-Werten (übrigens: in den Einstellungen f. Menu steht bei Standard-Theme und -Skin "Bob Ross" ...

Das ist ein sicheres Zeichen dafür, dass die Installation nicht sauber durch lief.
"Bob Ross" ist die Vorgabe, die im Code steht. Die wird durch die Werte aus der Datenbank überschrieben. Wenn also kein Thema oder Skin in der Datenbank gefunden wurde, bleibt Bob Ross stehen. Das Beispielthema und -Skin heißen "standard" und das sollte auch die Vorgabe im JobEditor sein.

Überprüfe doch mal, wie viele Einträge folgende Tabellen haben:

select count(*) from dbVdrAssistant.va_pageelem;
select count(*) from dbVdrAssistant.va_skin;
select count(*) from dbVdrAssistant.va_skinelem;
select count(*) from dbVdrAssistant.va_theme;

Gruß Geronimo

Hallo Martin,

Deine DB sieht soweit ganz gut aus

Zitat

Bei der letzten Neuinstallation ist mir diese Möglichkeit auch aufgefallen und ich hab sie darauf eingestellt, bei mir war nämlich iso-8859-15 voreingestellt.

Wenn ich mich nicht irre, arbeitet LinVDR mit iso8859-15 ...

Musst mal schauen, wie Du Deine Platte einbindest. Vielleicht kannst Du den Zeichensatz auch als mount-Option angeben.

Zitat

Vielleicht hab ich mich ungeschickt ausgedrückt. In "Bearbeitung -> Einstellungen -> Menu" steht als Standard "Bob Ross".

Yepp, das ist in der Tat eine völlig andere Baustelle.
Bei den Optionen des Job-Editors kann man hinterlegen, welches Thema und Skin als Vorgabe ausgewählt werden sollen. Das ist reiner Text und der liegt auch nicht in der Datenbank. Wenn die entsprechenden Einträge nicht gefunden werden, wird "standard" wieder zur Vorgabe ...

Ich habe mir daraufhin Deine Logdatei angeschaut. Das sieht erstmal nicht schlecht aus. Allerdings steht dort, dass der Author-Schritt fehlschlug.
Schau mal im Verzeichnis /var/tmp/Willi_wills_wissen_-_Von_A_-_Z dort sollte es eine log-Datei geben.
In der steht etwas mehr über die Fehlerursache.

Wenn Dir die Fehlerursache nix sagt, dann poste die Datei doch mal hier.

Gruß Geronimo

Zitat

ich hab jetzt mal das Ubuntu zurück auf utf8 gestellt und die Platte über Samba eingebunden. Hier kann man den Zeichensatz der Platte mitgeben sodaß alles gescheit angezeigt wird und beim Scan erfasst wird.

Das hört sich nach einem sehr guten Plan an

Zitat

Die Original-Log-Datei hab ich nicht mehr aber eine neuere, Ergebnis das Gleiche.

Wie Du sehen kannst, hat der Jobverarbeiter den abgebrochenen Job vorgefunden und mit dem vorletzten Schritt angefangen.

Zitat

Ich hab auch mal das Aufräumen abgestellt und da wird ja schon allerhand erzeugt.

Yo, das sieht garnicht schlecht aus. Eigentlich würde ich sagen, es sieht so aus, wie es sein soll, wären da nicht die Dateien in VIDEO_TS mit Benutzer "root".
Die dürften überhaupt nicht da sein. Könntest Du bitte mal schreiben, was Du geändert hast?

Hast Du bei den DB-Einträgen der Dienste den Benutzer root eingetragen, oder sind die Dateien ohne Dein Wissen root zugeordnet worden?

Für mich sieht das so aus, als hätte der Job anfangs 3 Aufnahmen gehabt und wäre dann auf 1 Aufnahme reduziert worden. Da die Dateigrößen gleich sind, denke ich, dass es jedesmal die gleiche Aufnahme war. Das wird aber offiziell garnicht unterstützt, deshalb würde mich sehr interessieren, wie die Dateien entstanden.

Für dvdauthor ist die Aufnahme natürlich nicht in Ordnung, wenn ein Menü für eine Aufnahme erzeugt wurde, im Arbeitsorder aber 3 Aufnahmen liegen ...

Ich würde Dir empfehlen, das Verzeichnis DVDAUTHOR komplett zu löschen und den Job nochmal anzustarten. Allerdings sollten die Dienste den Benutzer "vadaemon" haben. Nur der ServiceManager läuft unter dem Benutzer root.

Hoffe das hilft Dir weiter.

Gruß Geronimo

Moin Martin,

so wie es aussieht, ist die Konvertierung OK, aber weil ich davon ausging, dass man den Platz der Scheibe ausnützen will, ist es eine Datei zu wenig

Du könntest folgendes versuchen:

ln -sfn /var/tmp/Die_Kamele_aus_dem_Morgenland/DVDAUTHOR /dev/dvd

... und dann mit Xine o.ä. eine DVD abspielen.

Das sollte funzen und wenn Du dann wirklich nen Rohling mit 700MB bespielen willst, dann müsstest Du die ISO-Datei eben selbst erstellen. OK?
Wenn die Aufnahme 4 Gig hätte, wäre der Job erfolgreich durchgelaufen, deshalb bin ich mir nicht sicher, ob ich das Proggy deshalb ändern soll/will.

Zitat

... allerdings starte ich VdrAssistant als root, sollte aber nichts heißen

Das ist in keinster Weise vorgesehen und es könnte sein, dass sich die Benutzereinstellungen dann nicht speichern lassen. Von allen Anwendungen von VdrAssistant ist nur der ServiceManager dafür vorgesehen, im root-Modus zu operieren. Alle anderen Anwendungen sollten als normale Benutzer ausgeführt werden.
Der einzige Grund, VdrAssistant als root zu starten ist der, wenn man die (Vorgabe-)Einstellungen für alle Benutzer ändern will.

Gibt es einen besonderen Grund, warum Du das Programm als root startest?

Vielleicht habe ich ja noch was übersehen - dann wäre es hilfreich für mich zu erfahren, was als normaler Benutzer nicht funktioniert.

Gruß Geronimo

Hallo Martin,

herzlichen Dank für die positive Rückmeldung. Meines Wissens nach bist Du der Erste, der bestätigt, dass VdrAssistant funktioniert

Zitat

Es werden isos erstellt. Jetzt ist lediglich das Problem, daß die Menüs nicht funktionieren. Das Hauptmenü wird angezeigt, aber von hier geht garnichts. Habe an den jungfräulichen Skins und Themes nichts gemacht.

Das könnte daran liegen, dass ich ein völlig anderes Menü-Konzept (etwas komplizierter, dafür aber flexibler) verwende.

Wenn Du also bei Xine versuchst, mit der Maus das DVD-Menü zu bedienen, geht wirklich nix.
Wenn Du allerdings die virtuelle Fernbedienung von Xine verwendest (Ansicht/Tastenfeld) sollte sich darüber das Menü bedienen lassen. Genauso funzt es auch mit einer richtigen Fernbedienung am DVD-Player, oder wenn die DVD über das dvdselect-Plugin abgespielt wird.

Hoffe dass Du das auch bestätigen kannst.

Gruß Geronimo

Zitat

kannst du mir sagen was mir das sagen möchte:

Meine Glaskugel ist zwar noch nicht wieder aufgetaut, aber da gerade so toll die Sonne scheint, habe ich Sandalen an - also probier ich's mal ...

Du hast im Job angegeben, dass nur ausgewählte Tonspuren übernommen werden sollen.
Entweder hast Du bei der Aufnahme keine Tonspur ausgewählt, oder die Aufnahme hat keine Tonspuren (ja, ich weiß - ist unwahrscheinlich. Aber die Stellen mit der NPE ist auch unwahrscheínlich - trotzdem ist es passiert).
Was ich mir noch vorstellen könnte, ist, dass der Job beim ersten Durchgang vor dem Mux mit einem Fehler abbrach und jetzt beim wieder anlaufen fehlt ihm die Info zur Tonspur.
... oder projectX konnte beim demuxen die ausgewählte Tonspur nicht erzeugen (Fehler bei projectX?)

... oder Du hast einen Käfer gefunden, will sagen - an der Stelle habe ich was versaubeutelt ...

Du weißt ja: Toyota ...

Um genauere Ursachenforschung zu betreiben bräuchte ich die *_log.txt von ProjectX, eine Ausgabe von ls -l des betroffenen VDRSYNC.# Verzeichnisses, sowie Deine Aussage, ob die Aufnahme eine ausgewählte Tonspur hat und wenn ja, welche (vielleicht kannst Du die entsprechenden Sätze aus der DB posten?).

Gruß Geronimo

P.S. Ich warte noch auf Deine Rückmeldung zur Bedienbarkeit des DVD-Menüs

Hi,

Zitat

Hallo, leider kann ich keinerlei HD Aufnahmen in MKV umwandeln.

Wärst Du bereit, mir eine Aufnahme zu Sigi hochzuladen, dass ich sie untersuchen kann?
Für mich sieht es so aus, als hätte sich das Format geändert.

Zitat

und wie schon vorher jemand geschrieben hat, vdrproxy.pl brauch 100% cpu last nachdem eine epg abfrage kam.

Das Phänomen habe ich untersucht und es hängt wohl mit den Platten zusammen.
Bei LinVDR liegt die EPG.data in einer Ramdisk, sodass dort kein nennenswerter IO entsteht.
Ich habe auch versucht, ob es was bringt, wenn ich die Daten vom Dienst aus langsamer abhole, das ist aber nicht der Fall.
Das einzige, was Entlastung bringt, ist vdrproxy mit nice zu starten.
Das habe ich auch seinerzeit schon geschrieben.
Dann verbraucht der vdrproxy zwar immer noch die 100% CPU, aber davon ist dann ein großer Teil bei nice zu finden, stört also andere Prozesse weniger.

Deshalb mein Tip: EPG.data in eine Ramdisk auslagern, mit dem gleichen Sicherungsmechanismus wie bei LinVDR.

Gruß Geronimo

Hallo zusammen,

da das Thema vdrproxy und CPU Last immer mal wieder hochkommt, habe ich top von meinem kleinen LinVDR (PII) geschossen und hochgeladen.

Beim ersten Bild (vdrproxy.png) fängt die Übertragung zum EGP-Sammeldienst an.
Beim zweiten Bild ist die Übertragung im vollen Gange und beim dritten Bild sieht man, wie die Prozesse wieder abgebaut wurden.

Ach ja, der VDR ist nebenher noch dabei, einen Film zu schneiden und live-TV läuft auch

Wie man sehen kann, ist der Wait-Wert jedesmal auf 0 und vom nice-Wert könnte ja noch CPU auf andere Prozesse verteilt werden.
Somit ist (zumindest für mich) alles im grünen Bereich

Gruß Geronimo

Huch - eine Frage

muss erstmal den Staub von mir abschütteln

Zitat

Der Installer connected die Datenbank

Gratuliere! - Damit hast Du die schlimmste Hürde gemeistert!

Zitat

taskConfig(ERROR) - you don´t have write permission for directory configDir

Wenn es sudo auf OSX gibt, brauchst Du garnix machen, nur runterscrollen und "Konfigurationsdateien via sudo installieren" aktivieren - siehe Bild.

Wenn es kein sudo gibt, ist etwas Handarbeit gefragt.
Je nach Java-Implementierung gibt es unterschiedliche Verzeichnisse.
Standard ist /etc/.java/.systemPrefs

Leute wie Suse und Co halten sich natürlich nicht an solche triviale Standards.
Dort werden die Systemeinstellungen im Bereich des JDK abgelegt (ja doch, ist sehr sinnig )
Du hast ja die JAVA_HOME variable gesetzt.
Unterhalb des Verzeichnisses gibt es ein "jre" und darunter könnte es ein ".systemPrefs" geben.

Der Installer prüft meines Wissens nach nur das Standard-Verzeichnis.
Ich habe für Suse mal was eingebaut, aber das ist mir jetzt nimmer präsent.

Wenns klemmt - einfach mal schauen, ob der Installer unter /etc/.java/.systemPrefs ... Verzeichnisse und Dateien angelegt hat. Für den Fall, dass danach der Client nicht tut, mal versuchen, den Baum von /etc/.java/.systemPrefs nach <JAVA_HOME>/jre/.systemPrefs kopieren.

Über weitere Rückmeldung würde ich mich sehr freuen!

Gruß Gero