Beiträge von theVIPER

Hallo,

Zitat

Original von Blume
So sieht meine channels.conf im Augenblick aus:

:Analog
ARD:175250:B6C0D45:C:0:301:300:0:A0:1:0:0:ard.de
ZDF:182250:B6C0D45:C:0:301:300:0:A0:2:0:0:zdf.de

Ich hoffe jemand kann mir sagen, was ich falsch mache. Meine Frequenz Daten habe ich direkt von ISH (Velbert)

Alles anzeigen

Vielleicht liegt das ja einfach daran, dass die Frequenzen der Analog-Sender regional differieren?

Bei mir sieht das ganze nämlich so aus (BW/südlich Karlsruhe):

ARD Analog:203250:B6C0D45:C:0:301:300:0:A0:28106:0:0:0
ZDF Analog:551250:B6C0D45:C:0:301:300:0:A0:28006:0:0:0

Zwei Möglichkeiten die richtigen Frequenzen rauszubekommen.
Einerseits kannst du das Skript von Wirbel einsetzen. Dazu muss aber Perl mit den Modulen für ivtv-Support installiert sein. Ist vielleicht nicht jedermanns Sache...
Andererseits einfach einen Fernseher mit automatischen Sendersuchlauf bemühen und dort dann Band/Kanalnummer ablesen und mit Hilfe der Kanaltabelle im VDR-Wiki die Frequenz nachschlagen. Bei mir waren das C/09 und C/31.

Hinter A0 sollte übrigens die Service ID eingetragen werden, falls du die Sender korrekt mit tvtv programmieren willst.

Zitat

Zitat aus AnalogTV-Plugin HOWTO
In die Spalte SID sollte mit Hilfe der beiliegenden "ChannelMap.h" die Service ID des jeweiligen Senders eingetragen werden. Dadurch wird es problemlos möglich, auch analoge Sender mit Hilfe des tvtv-Plugins zu programmieren.

Grüße theVIPER

Zitat

Original von Urig
Bei mir macht folgende Zeile genau das gewünschte:

sed -e "s/$/\r/"
...
\r ist dabei ein von sed interpretiertes Steuerzeichen.

Kann es sein, dass du 'ne andere Version von sed hast? Meine (GNU sed version 3.02) ignoriert den Backslash völlig und gibt nur den Buchstaben r aus.

Zitat

Original von Urig
theVIPER:
Fast, aber nicht ganz!

Der musste jetzt sein, oder?

Zitat

Original von Urig
Deinem Ansatz kommt die Tatsache in die Quere, dass Backticks immer die letzten Zeilenumbrüche entfernen. Dein `printf '\r\n'` produziert also nur ein \r. (Das ist zum Glück auch genau das, was du hier brauchst. )

Das wußte ich noch nicht... tja, man lernt halt nie aus. Vielen Dank für die nachfolgenden Erläuterungen in deinem Post!

Grüße
theVIPER

Hallo,

na dran, aber noch nicht ganz...

sed kennt keine \n oder \r in der Ersetzung. Man muss auf printf in Verbindung mit Backticks zurückgreifen:
sed -e "s/$/`printf '\r\n'`/" file >file.out

Wenn man auf vollständige reguläre Ausdrücke aus ist, kann man natürlich auch auf Perl zurückgreifen. Ist zwar nicht unbedingt bei allen Distris vorhanden, aber dann ist auch ein "in place"-Bearbeiten mit automatischen Backups möglich:
perl -p -i.bak -e "s/\n/\r\n/" file

Hier funktioniert "s/$/\r\n/" übrigens nicht wie gewünscht, da Perl die \n am Zeilenende, im Gegensatz zu sed, nicht rausfiltert. "s/\n$/\r\n/" dagegen schon, macht aber auch nicht unbedingt Sinn. Und außerdem sind wir ja alle tippfaul

Grüße
theVIPER

Zitat

Original von willibutz
Hi tester,
Es ist wohl das Problem, das Du geschildert hast. Habe im dvd.log Meldungen gefunden wie:
- unexpected EOF while looking for matching `''
- syntax error: unexpected end of file
Der Name der iso-Datei ist "Director's cut usw.iso"

Ich weiß aber nicht, wie ich den Namen ändern kann. Im Pfadnamen gibt es solche Zeichen nicht. Und den kann man wohl auch nicht einfach ändern.

Alles anzeigen

Am besten beim Erstellen der DVD im Disknamen und allen Aufnahmen die "bösen" Zeichen entfernen.

Zitat

Tut mir leid, daß ich nerve. Nochmal - was muß ich machen, um z.B. das Patch vdr-burn-0.0.5-0.0.6f.diff.gz zu installieren?

Da wirst du um's Neukompilieren leider nicht herumkommen. Die üblichen Patches unter Linux sind nämlich alle auf Quelltextebene, sogenannte Diff-Dateien. Sie enthalten in textueller Form die Änderungen zwischen zwei Versionen des Codes. Zum Einspielen kommt dann wieder einer dieser "kryptischen" Linuxbefehle zum Einsatz.

Wenn du aber bei LinVDR bleiben und nicht gleich in die Entwicklung einsteigen willst, empfehle ich dir die Patches (diesmal in binärer Form) von Mark Twain. Findest du im LinVDR-Forum, die Beiträge sind leicht daran zu erkennen, das sie mit "MT" beginnen.

Zitat

Selbst übersetzen sollte kein Problem sein. Aber die LinVDR-Distribution liefert keinen C-Compiler. Sicher, läßt sich alles nachinstallieren. Gewußt wie!? Im Übrigen wollte ich nicht überheblich klingen. Tut mir leid, wenn das so rübergekommen ist! Der Einstieg bei Linux scheint nur ziemlich kompliziert. Bei DOS/Windows gibt es keine Scripte etc. Vielleicht hast Du einen Tipp, wo ich das Hintergrundwissen herbekomme, um mitreden zu können. Ich bin ja nicht blöd, aber das muß doch irgendwo stehen. Irgendwie muß man doch mal den Einstieg finden.

Alles ist relativ: ich erinnere mich noch, wie ich vom C64 auf einen PC umgestiegen bin und dachte "Da sind ja ganz komische Befehle, das raffst du doch nie...". Der erste Linux-Schock fiel dann schon weniger heftig aus, war aber auch mit viel Lernaufwand verbunden.
Außerdem gibt es unter DOS sehr wohl eine "Skriptsprache" oder als was würdest du Batch-Dateien bezeichnen? Windows besitzt den Windows Scripting Host, das weiß fast nur keiner.

Im Übrigen wollte ich genausowenig belehrend klingen, wie du überheblich Am Schluss sind einfach die Pferde mit mir durchgegangen...

Grüße
theVIPER

Zitat

Original von willibutz
Wo kann ich denn die Größe ändern? Im Menü? Da gibt es keine solche Option. Soll ich das Plugin updaten. Wenn ja, stehe ich vor einem neuen Problem, denn ich weiß nicht wie.

Die Option ist in neueren Versionen vom VDR-Hauptmenü unter Einstellungen/Plugins/burn zu finden. Macht die Sache etwas einfacher als hartkodierte Werte

Andernfalls ist selbst übersetzen angesagt. Die Definition in einer der Header-Dateien des Burn-Plugins lautet glaub ich DVDSIZE.
Wie man den VDR / Plugins selber kompiliert? Normale gcc-Umgebung, ist alles in C geschrieben, sollte für einen alten Hasen ja kein Problem sein. Ansonsten

Zitat

bin schon über 20 Jahre im Geschäft - habe Assambler, Pascal und C programmiert und bin, glaube ich - bei aller Bescheidenheit, ein hervorragender Programmierer. Deshalb wundert es mich schon ein bißchen, daß es bei diesem (Linux-)Projekt bei jeder neuen Sache erst einmal Probleme gibt. Ich dachte, Linux ist letzendlich das Non+Ultra verglichen mit Windoofs. Na ja, ist auf jeden Fall hoch-interessant und ich hoffe, ich kann mich beteiligen - bei der Erstellung von guter Software für die Allgemeinheit. Im Augenblick bin ich jedoch auf Euch angewiesen.

Dann solltest du ja auch wissen, dass eigentlich keine Software fehlerfrei ist. Und schaut man sich den Funktionumfang an, den der VDR inklusive Plugins abdeckt, kann man sich ja leicht denken, dass es vielleicht mal an der ein oder anderen Stelle hakt.
Nicht zu vergessen, dass die ganze Arbeit von den Entwicklern in ihrer Freizeit durchgeführt wird und mal störende Reallife(tm)-Einflüsse dazwischen kommen.
Und die riesige Hardwarevielfalt auf der unser Lieblings-Opensource-Projekt läuft... und und und

Langer Rede kurzer Sinn: bei mir häuften sich am Anfang auch die Macken, aber nach einer gewissen "Einfahr"phase läuft mein VDR jetzt (fast) komplett problemlos

Grüße
theVIPER

Hallo,

ist mir auch schon einige Male passiert.

Wahrscheinlich ist das vom Burn-Plugin erzeugte DVD-Dateisystem ein kleines bisschen zu groß geworden.
Die Berechnung verschätzt sich ab und zu bei der Größenbestimmung. Deshalb ist die Voreinstellung für die DVD-Größe von 4462 MB teilweise zu optimistisch.

Beim eigentlichen Brennen wird dann erst die tatsächliche Größe des Rohlings überprüft. Und falls die für die zu brennenden Dateien nicht ausreicht kommt halt die Schublade raus und will einen Rohling mit mehr Platz...

Bei neueren Versionen (0.0.6irgendwas) kann man die Größe in den Optionen abändern. Ich verwende 4400 MB, das sollte als Reserve auf jeden Fall ausreichen. Bei älteren Versionen muss man eine Definition im Quellcode abändern und das Plugin neu compilieren.

Grüße
theVIPER

Zitat

Original von PeterD
Genauso bescheuert find ich aber auch die verwendung von int als bool, ala:

int test
...
if (test) {
...
}

Leider GERADE unter unix üblich.

Offensichtlich hat jeder dieser *piiiep* vergessen das es nirgends definiert ist das FALSE 0 ist, und man bereits beim nächsten compiler auf die fresse fliegen kann.

Für diese zwei punkte hab ich mal ein schönes "coding rule" dokument bei einem unserer code-lieferanten gefunden. Seht zu empfehlen.

gruss Peter

Alles anzeigen

Nur mal so zum Blick über den Tellerrand:
Es gibt auch Programmiersprachen, in welchen eine solche Überprüfung absolut korrekt ist.

Als Beispiel wäre hier Perl zu nennen. Allerdings gibt es hier sowieso keine strikte Typeinordnung und überhaupt keine boolschen Werte im eigentlichen Sinne.
Stattdessen werden alle Typen (auch Strings!) im boolschen Kontext quasi in Integerwerte umgewandelt, wobei dann 0 false entspricht und alle anderen Werte true sind.
Das geht dann sogar so weit, dass sowohl der leere String "" als auch ein String, der nur die Ziffer Null enthält "0" als false interpretiert werden. Das kann dann auch in ungünstigen Fällen in die Hose gehen, weshalb Perl auch noch den Stringvergleich mit eq kennt.

Um wieder in C/C++-Gefilde zu kommen (ja, ich weiß, dass es hier deutliche Unterschiede gibt und C++ nicht einfach ein aufgebohrtes C ist - nur für den Fall, dass sich jemand schon in Flamewar-Stellung gebracht hat ;)):
Und dann gibt es ja auch noch die variabel anhand der Plattform definierten Datentypen. int muss schließlich nicht gleich int sein...
Beispiele hierfür sind dann DWORD oder aber auch BOOL. Und Letzteres ist (zumindest bei Visual C++ unter Windows) auf int gesetzt. Passend dazu gibt es dann auch definierte TRUE und FALSE Werte, die dementsprechend auf 1 bzw. 0 gesetzt sind.
Und um hier korrekten Code zu erzeugen muss man eben folgende Konstrukte erstellen:

BOOL test;
...
if (test == TRUE)
{
  ...
}

Weil ansonsten hat man ja grade den bemängelten Integer-Bool-Gleichschalt-Vergleich. Andererseits sieht das Ganze natürlich verdammt nach dem schon bemängelten Vergleich gegen true (nicht TRUE!) aus, ist hier aber syntaktisch korrekt und sogar notwendig.

Grüße
theVIPER

Hallo,

Patch gibt's hier:
http://www.vdr-portal.de/board/thread.php?threadid=29849

Oder aber einfach das DVD-Plugin patchen, wie von mir im selben Thread vorgeschlagen. So läuft's bei mir seit einiger Zeit absolut problemlos.

Grüße
theVIPER

Hallo,

kein Fehler: die burnmark.sh muss durch die Version ersetzt werden, die beim Plugin dabei ist (liegt in einem Unterverzeichnis des Quellcodes).

Die Größe der Aufnahmen wird bei den neuen Versionen nämlich durch dieses Skript direkt bei Auswahl einer Aufnahme errechnet.
Dazu sollte aber auch eine aktuelle vdrsync-Version vorhanden sein, da dieses hierzu herangezogen wird. Dabei werden dann auch die gesetzten Schnittmarken bei der Berechnung berücksichtigt. Ich glaube aber die 0.1.3PRE1 sollte reichen, dennoch wäre ein aktuellerer Snapshot ratsam. Diese kommen dann auch mit dem geänderten AC3-Format neuerer VDR-Versionen zurecht.

Soweit ich mich erinnere steht das übrigens auch in der angepassten README drin...

Grüße
theVIPER

Zitat

Originally posted by _Frank_
entschuldige, bei dem Patch ging es eigentlich nicht um die Wiedergabe von DVD's, sondern um die Aufnahme von Digital-Audio-Streams, wenn "Dolby Digital benutzen" nicht aktiv ist. Damit man DVD's mit digital-Audio von Aufnahmen erstellen kann oder diese später mit entsprechender Technik wiedergeben kann. Ich zb. besitze derzeit nicht das nötige Equipment. Der Code des Patches stammt auch aus dem vdr, allerdings aus der Version, 1.3.17, bei der konnte man dies für die Aufnahme noch auswählen.

Schon klar. Aber wie du bereits selbst gesagt hast:

Zitat

Originally posted by _Frank_
Das dvd-Plugin verlangt derzeit nach der Einstellung, daß ich Dolby Digital nicht benutze, damit ich überhaupt was höre.

Wenn man nun also das DVD-Plugin patcht, dann kann man unabhängig von "Dolby Digital benutzen" auf nicht Dolby-fähiger Hardware DVDs mit Ausgabe von Stereoton schauen.
Trotzdem ist es dann aber möglich durch Einschalten der Option die AC3-Spur bei Aufnahmen mit zu speichern. Das beeinträchtigt die normale Wiedergabe ja nicht, da immer auch noch eine MP2-Stereo-Spur vorhanden ist.

Mir war nicht bekannt, dass bei 1.3.17 eine solche Option vorhanden war, da ich von 1.2.6 direkt auf 1.3.20 gewechselt habe. Aber da es eigentlich nur bei der Wiedergabe von DVDs zu Einschränkungen kommt, falls man nicht mit entsprechender Hardware ausgestattet ist (wie ich übrigens auch), stellt das Patchen des Plugins eine weitere Option dar.

Ich will ja auch genau das selbe erreichen, nämlich die Möglichkeit Dolby Digital aufzunehmen um es eventuell später nutzen zu können.

Grüße
theVIPER

Hallo,

wäre es für die DVD-Wiedergabe nicht einfacher, das DVD-Plugin zu patchen, anstatt den kompletten VDR umzukrempeln? Ich meine damit steigt eigentlich nur die Gefahr, das es zu unangenehmen Nebenwirkungen kommt.

Soweit ich das im Code des Plugins gesehen hab, müssen nur an vier Stellen Änderungen durchgeführt werden.
Am einfachsten alle Checks

if (Setup.UseDolbyDigital...)

durch

if ((false && Setup.UseDolbyDigital)...)

und alle

if (!Setup.UseDolbyDigital...)

durch

if ((true || !Setup.UseDolbyDigital)...)

ersetzen... das wär's!

Natürlich kann man gleich die reinen boolschen Werte reinsetzen, aber mit der Variante oben bleibt der Code wenigstens weiterhin verständlich.

Grüße
theVIPER

Hallo,

bevor ihr euch hier zerfleischt geb ich euch doch lieber meinen Hotfix für das Problem (siehe Attachment).
Damit wird der bisherige Zustand wiederhergestellt. Dass heißt: Bearbeiten von Aufnahmen und DVD-Titel ist wieder möglich, aber die automatische Benennung von Archiv-DVDs ist deaktiviert.
Dann klappts auch wieder mit den lesbaren Menüs

Zitat

Originally posted by ralf1970
...sondern mir ist ein Fehler unterlaufen (und bis jetzt weiß ich noch nicht mal welcher).

...Wenn du einen Fix für das Problem hast bau' ich den sofort ein, wenn ich es selbst suchen muß dauert es noch ein paar Tage.

Irritiert
Ralf

Hinsichtlich der Fehlersuche helfen vielleicht die folgenden Codeschnipsel

menuitems.c:
void cBurnMenuEditStrItem::SetNewValue(char* Value)
{
	free(value);
	value = strdup(Value);
	Set();
}


...


cBurnMenuEditRecordingItem::cBurnMenuEditRecordingItem(
		cBurnRecording *Recording):
		cBurnMenuEditStrItem(bitEditRecording, Recording->Title(), Recording->mName,
				JOBNAMELEN, TitleChars) {
	mFileName = strdup(Recording->FileName());
}




menuburn.c:
void cBurnMenuBurn::DisplayRecordings(void) {
...
	if (Pending != NULL) {
		mDiskType = Pending->mDiskType;
		for (cBurnRecording *rec = Pending->First(); rec; rec = Pending->Next(rec)){
			Add(new cBurnMenuEditRecordingItem(rec));
			total += ScanRecordingSize(rec->FileName(), Pending->mDiskType);
		}
	} else
		Add(new cBurnMenuTextItem(tr("No recordings marked"), true));
...
}

Du hast die Methode SetNewValue hinzugefügt, die verwendet wird um die Bezeichnungen zu setzen. Nur leider wird der übergebene String hierbei kopiert, weshalb sich das ursprüngliche Recording->Title() nicht ändert. Die editierbaren Felder im OSD arbeiten nämlich mit den original Pointern auf die Strings. Deshalb ändert sich zwar das Eingabefeld, der für's Brennen relevante Titel ändert sich aber nicht.
Jetzt noch ohne Code: Beim DVD-Titel speicherst du den Menueintrag noch mal extra zwischen, um später die Variable zu aktualisieren. Bei den Aufnahmen hast du das versäumt.

Bitte nicht als Belehrung verstehen... jeder macht mal Fehler, sogar ich

Grüße
theVIPER

Zitat

Original von nelwyn
Hmmm glaub ich fast net, dass die fehlerhafte Stellen haben, denn ich checke die immer nach dem zusammenschneiden noch mal durch. Mir kam nix merkwuerdig vor Viper. Aber vieleicht such ich ja auch nach dem Falschen. Woran kann ich deiner Meinung nach erkennen ob eine Aufnahme fehlerhaft ist?

Vielleicht keine direkt fehlerhafte Stelle... nach nochmaligem Check des Logs bin ich der Ansicht, dass ganz zum Schluss noch ein überzähliger Marker ist:

1257 Mbytes of 1257 read
...
DEBUG Cut detected at 1282975071 before GOP 5717
...
dropping frame with time 1282970959 cause 1282970959 < 1282975071


Start Sync failed for stream c0 while trying to drop Frames until 1282975071
cutlist: 903074271::1063000671::44424
cutlist: 1098467871::1148623071::58356
cutlist: 1189706271::1226599071::68604
cutlist: 1282975071::1283003871::68612
syncing start of chunk 3 in c0 failed

Das Problem hatte ich in ähnlicher Form auch schon. Manchmal setzt Noad ganz am Schluss der Aufzeichnung noch eine Schnittmarke. Darüber stolpert vdrsync dann und nix is mit Brennen.

Überprüf einfach mal, ob bei dir eine solche Marke vorhanden ist und entferne sie falls nötig vor dem Schneiden.

Ich hab mir die Logfiles mal angesehen, kann aber auch nichts weiter Hilfreiches dazu sagen.

Zumindest bei "Drunken Master" läuft vdrsync ohne Fehler durch und der Hänger tritt erst beim Requantisieren auf.
Bei "Alarm für Cobra 11" scheint es Probleme beim Synchronisieren zu geben. Ist die Aufnahme vielleicht an dieser Stelle fehlerhaft?

Ansonsten muss ich leider passen.

Zitat

Original von nelwyn
hmmm sagt mal funktioniert das bei euch tatsaechlich. Ich hab die Zeilen reingenommen und er bricht mir ab. Er macht zwar ein AC3 File jedoch kommt er nicht zum brennen. Habs auch mit dem neusten MT Patch probiert da ich gesehen hab dass Mark entsprechend eurer Anleitung gepatcht hat.

Leider bekomm ich keine laufende DVD mit AC3 hin. Nach dem Patch hab ich dann noch mal auf die vdrsync.pl verlinkt und er hat dann zumindest gebrandt jedoch mit stotter AC3.

Kann mir einer helfen?

Kannst du mal bitte in der vdrsync-burn.pl

my $debug             = 0;

zu

my $debug             = 1;

ändern (sollte Zeile 83 sein) und anschließend hier die Ausgabe posten?

Kann natürlich sein, dass du eine "ungünstige" Aufnahme erwischt hast... vielleicht Änderung des Audioformats bei Werbung oder eine hängengebliebene Schnittmarke ganz am Ende der Aufnahme.

Grüße
theViper

Zitat

Originally posted by MarcTwain
Kommt in den nächsten Patch... Danke.

Keine Ursache, freut mich wenn anderen damit geholfen ist

Zitat

Originally posted by MarcTwain
Was mein ihr zu einem neuen Patch mit
...
AC3 Patch fuer vdrsync-burn.pl

Und dann auch noch fett angekündigt
Dafür hat sich die Mühe ja schon gelohnt... mal abgesehen davon, dass ich jetzt selbst wieder DVDs mit AC3 brennen kann

Hallo,

Zitat

Edit: Erledigt!
Hab's per Hand ersetzt.

War bei dieser Änderung ja grad noch so zu handhaben

Für alle die es dennoch mit dem Diff-File patchen wollen: -l ist die "Zauber"-Option.

cat vdrsync-patch.diff | patch -l -p1 --dry-run

Ist beim Copy&Paste über SSH wohl doch irgendwas mit den Tabs/Leerzeichen passiert.
Ich hab's auch nicht noch mal getestet, ob's nach erneutem Zurückkopieren auch wirklich funktioniert... war dann doch etwas spät dafür

Zitat

Jetzt funzt's auch mit AC3 Ton!

Freut mich das zu hören

Grüße
theVIPER

Hallo,

ich hoffe es denkt sich jetzt keiner
"Na toll, ist ganz neu im Portal und hat zufällig gleich am Anfang 'ne Lösung parat. Die muss er jetzt natürlich überall reinposten, um sich produzieren zu können!".

Das ist jetzt nämlich inzwischen der dritte Thread, in dem ich auf eine mögliche Lösung hinweise:
http://www.vdr-portal.de/board/thread.php?postid=271820&sid=#271820

Es scheint sich hierbei um eine Inkompatibilität zwischen VDRSync 0.1.3PRE1 und dem seit VDR 1.3.19 veränderten AC3-Stream zu handeln.

Um noch mal auf meinen einleitenden Satz zurückzukommen: ich will mich hier keinesfalls aufspielen, nur weil ich einen (möglichen) Workaround anzubieten habe. Der Gedanke hinter den Verweisen liegt darin, dass nicht unbedingt jeder, bei dem das Problem auftritt, auch jeden dieser Threads gelesen hat. Und AC3 gegen asynchronen Ton zu tauschen ist auch nicht unbedingt die Lösung

Grüße
theVIPER

Hallo,

schon der dritte Thread in dem jemand von diesem Problem berichtet

Um hier unnötige Crossposts zu vermeiden, verweise ich einfach mal auf meine mögliche Lösung für das Problem mit den leeren AC3-Dateien:

http://www.vdr-portal.de/board/thread.php?postid=271820&sid=#271820

Ich hoffe das hilft weiter

Grüße
theVIPER

Hallo,

mögliche Lösung für dieses Problem gibt es hier:

http://www.vdr-portal.de/board/thread.php?postid=271820&sid=#271820

Grüße
theVIPER