MovieCutter

[chris86]

Irgendwie wird die Sache immer mysteriöser, aber ich glaube inzwischen, dass die Probleme auf meinem CRP nichts mit MC, weder 1.4 noch 2.0, zu tun haben.

Hier meine neuen Erkenntnisse:
Nachdem ich eine gute Woche aushäusig war, habe ich gestern Morgen die während meiner Abwesenheit angefallenen Aufnahmen geschnitten, und zwar nicht mit MC - mit welcher Version auch immer - sondern mit der built-in Schnittfunktion der Firmware, insgesamt 7 Aufnahmen.

Nach einem "normalen" Neustart kam es zur Festplattenüberprüfung und von den 7 waren 4 Aufnahmen verschwunden. Der Effekt des "Aufnahmenfressers" ist offensichtlich unabhängig von MC, sondern ist in der Firmware begründet, oder?

Danke für diese Erkenntnis!
Damit können wir es nun praktisch als erwiesen betrachten, dass das Problem nicht beim MovieCutter zu suchen ist, sondern an deinem Topf liegt! (was ich ja eh schon länger vermutet habe)

Trotzdem einige wichtige Punkte, um das Problem aufzuklären:

1. Kannst du dich noch an die Reihenfolge erinnern, in der du geschnitten hast?
   Trifft es zu, dass die 4 verschwundenen Aufnahmen genau diejenigen waren, die du zuletzt geschnitten hast? Oder ist unter den verschwundenen Aufnahmen eine dabei, die vor einer anderen geschnitten wurde, welche aber erhalten geblieben ist?
2. Warum hast du denn nach dieser Schnitt-Aktion nicht mal einen HDD-Check durchgeführt?
   Das hätte maximal 2 min gedauert, und deine Aufnahmen könnten (wahrscheinlich) noch leben...
   Außerdem wäre es für mich äußerst wichtig herauszufinden, ob der HDD-Check wirklich immer zuverlässig vor dem drohenden Aufnahmenfresser warnt. Und da du der einzige bist, der diesen derzeit produziert, wäre das ein wertvoller Test gewesen...
   (PS: Die Frage ist nicht böse gemeint, und erwartet auch keine Antwort^^ - aber es wäre ganz insbesondere in deinem Fall äußerst ratsam, wenn du das künftig tun würdest...)
3. Eine wichtige Frage von mir hast du immernoch nicht beantwortet:
   Hast du jemals ein Firmware-Update durchgeführt und danach eine alte Settings-Datei eingespielt?
   Und falls ja: Hast du danach deine Settings einmal auf die Werkseinstellungen zurückgesetzt, neu gestartet, und dann geschnitten, ohne zuvor eine Settings-Datei einzuspielen?
   Das wäre ein (sehr einfach zu behebender) möglicher Grund. Und das würde ich wirklich gerne als Verursacher ausschließen können.

Meine aktuelle Theorie: Die Platte ist in Ordnung, die Firmware aber kommt nicht mit dem "4K Advanced Format" der WD zurecht. Mein nächster Versuch ist die Festplatte neu einzurichten im Kompatibilitätsmodus (Jumper auf 7-8). Das kann aber noch ein paar Tage dauern.

Bevor du diesen riesigen Zirkus durchziehst, alle Daten zu sichern und die Platte komplett neu zu formatieren, probiere doch bitte zuerst einmal die beiden wirklich einfachen und schnellen möglichen Lösungen aus:

1. Werkseinstellungen wiederherstellen
   (Du kannst ja deine aktuellen Settings vorher speichern, und meinetwegen nach einer Woche oder so wieder einspielen... Und die TAPs bleiben dabei sowieso alle erhalten.)
2. Regelmäßig nach der letzten Schnitt-Aktion des Tages einmal die Festplatte prüfen
   (Der neue MC hat die Möglichkeit, die Prüfung per Knopfdruck abzubrechen, so dass du sie wirklich nur beim letzten Schnitt durchlaufen lassen musst. Außerdem kann die Prüfung mit der neuen Version im Menü manuell angestoßen werden, so dass du sie nach Belieben ausführen kannst.)

Abgesehen davon, kannst du mit dem Jumper das "Advanced Format" nicht ändern.
Die Festplatten-Zugriffe würden dadurch zwar effizienter (also schneller) - aber ein Dateiverlust-Problem dürfte das eigentlich nicht begründen (außer die Firmware deiner Festplatte hat einen gewaltigen Fehler!)

RbN startete nun und versuchte neue .nav zu erzeugen. Das dauerte eine gefühlte Ewigkeit, ist aber letztendlich nicht von Erfolg gekrönt:

Code: Alles auswählen

2014-03-26 08:06:31 RebuildNAV: 12 files found, 3 files marked for processing.
2014-03-26 09:06:30 RebuildNAV: Scanne '/DataFiles/Superhero Movie.rec'
2014-03-26 09:06:30 RebuildNAV:   Packet size = 192
2014-03-26 09:29:36 RebuildNAV:   [b]0 nav records. File not created.[/b]

waren das Dritte Sender der ARD wie zB. SWR?

Auch wenn das nichts mit MC zu tun hat, würde mich interessieren, weshalb RbN hier fehlschlägt. -> Hast du mal probiert, ob sich die Aufnahmen überhaupt abspielen lassen? -> Könntest du diese 3 Aufnahmen einmal mit einem Hex-Editor öffnen, und mir eine Kopie der ersten paar Kilobytes bzw. einen Screenshot der ersten Bildschirmseite zukommen lassen?

[FireBird]

[quote="chris86"]Auch wenn das nichts mit MC zu tun hat, würde mich interessieren, weshalb RbN hier fehlschlägt.[/quote]
Wenn ich mich recht erinnere, wird in diesen Streams kein PCR übertragen und somit kann RbN keine Timing-Information auslesen. Auch der Topf kann keine .nav mehr herstellen, eine manuell erstellte Kopie endet auch mit einer 0-Byte-nav.

[chris86]

Wenn ich mich recht erinnere, wird in diesen Streams kein PCR übertragen und somit kann RbN keine Timing-Information auslesen. Auch der Topf kann keine .nav mehr herstellen, eine manuell erstellte Kopie endet auch mit einer 0-Byte-nav.

"in diesen Streams"? Also in denen von Herbert? Genau deshalb wollte ich ja in die Streams hineinschauen...
Apropos: Nach meinen Tests für den MC scheint der Topf die PCR-Info in der nav garnicht unbedingt zu brauchen. Zumindest kommt er damit klar, wenn einzelne Timestamps nicht stimmen...
Entscheidend ist aber, dass für jeden Frame ein nav-Record vorhanden ist. Hast du mal versucht, einfach trotzdem eine .nav zu erzeugen, und beim Timestamp meinetwegen 0 einzutragen? Oder einen Phantasiewert (lineare Interpolation der Zeit)?

[FireBird]

Damals habe ich mich gespielt, frag mich nicht mehr nach allen Details.

[Wolfman]

Das mit den fehlenden PCRs bei den 3. könnte hinkommen - ich hatte jetzt eine Aufnahme von NDR HD, an der sich der TSDoctor verschluckte... (zu MC kann ich aber aktuell nichts sagen - die damals bei mir verschwundenen Aufnahmen waren von verschiedenen Sky Sendern, wegen diverser anderer Baustellen habe ich diesbezüglich leider nicht mehr testen können).

[Maliboy]

Maliboy, zuerst eine Gegenfrage: Was genau willst du rausbekommen?

Wer oder was hier gelöscht hat ...

Folgende Aktionen solltest du unbedingt mal durchführen und hier berichten:
Wann, wie und von wem wurden die .rec-Dateien gelöscht?
Hierzu hat Twilight dir bereits einen guten Tipp gegeben, den du (glaube ich) falsch interpretiert hast. Es ist nicht entscheidend, wie alt die .inf- und .nav-Dateien waren, sondern wann die Löschung der zugehörigen .rec stattgefunden hat.
-> Hast du das TAP TimerDiags installiert? (Falls nein, installiere es bitte!)
-> Hast du TimerDiags im Autostart und die Option Rec-Monitor aktiviert? (Falls nein, tu das bitte!)
-> Falls ja zu den beiden obigen Fragen, stelle uns doch bitte mal die Datei TAPSystem.log aus dem Verzeichnis /ProgramFiles zur Verfügung. Nur so lässt sich ermitteln, ob das Problem denselben Ursprung hat.

Ich hatte Twilight schon richtig verstanden und ich habe Timer Diags auch im System am laufen. Ich kann Dir aber aktuell NICHT sagen, ob die besagten Dateien von mir gelöscht wurden oder nicht. Ich kann Dir nur sagen, das ich ab und an via FTP auf den TOPF schaue und da ein oder zweimal besagte Karteileichen gesehen habe. Ob die nun beim lschen über FastSkip, über SmartFiler oder durch das System entstanden sind, keine Ahnung.

Welche Festplatte ist in deinem Topf verbaut? (Marke, Modell)
-> Lässt sich mit dem TAP HDDInfo von Firebird ermitteln.

Die Frage hatte ich Alex hier schon beantwortet: Seagate ST31000322CS (Laut Alex keine 4K Platte).

Verwendest du Timeshift?
-> Wenn ja, wie oft oder dauerhaft? Auch während gleichzeitigem Aufnehmen?

Dauer an.

Status des Dateisystems regelmäßig kontrollieren
Wenn du weitere Datei-Verluste vermeiden möchtest, ist die derzeit vielversprechendste Methode, das Dateisystem regelmäßig auf Fehler zu überprüfen.
Damit kann (zumindest in der Theorie) festgestellt werden, ob beim nächsten Reboot Aufnahmen verschwinden könnten, oder nicht.
-> Die neue MovieCutter-Version (die vermutlich heute noch veröffentlicht wird), wird in ihrem Menü eine neue Option enthalten, mit dem sich das Dateisystem prüfen lässt.

Also aktuell wird es nur bei einen Absturz geprüft, der seit dem ich ein paar Downgrades durchgeführt habe ja geringer geworden ist.

[Twilight]

[quote="Maliboy"]Ich kann Dir aber aktuell NICHT sagen, ob die besagten Dateien von mir gelöscht wurden oder nicht.[/quote]wenn du nach diesen datein in timerdiags suchst und sie nach dem start des taps gelöscht wurden ist die wahrscheinlichkeit groß das du es nciht warst...

twilight

[db1]

Interessant, dass nun auch Dateien verschwunden sind, die mit Mitteln der Firmware geschnitten wurden. Ich hatte leider augenblicklich keine Zeit zusätzliche Aufnahmen zu schneiden und testen und die gewollten Aufnahmen bleiben bei mir vorerst ungeschnitten

Das gewisse mit den Mitteln der Firmware geschnittene Aufnahmen von RbN nicht mehr "repariert" wurden ist mir auch aufgefallen, das war für mich ein Hauptgrund zu MC umzusteigen.

Was mir zur ganzen HD Diskussion noch einfällt, ich bin ziemlich sicher (leider nicht 100%ig) dass bei mir auch Dateien, die ich auf der externen HD (gemountet) geschnitten habe, verschwunden sind.

Bin schon auf die neue Version mit dem Dateisystem-Check gespannt und verspreche damit zu testen!

[klassikmann]

Bevor ich auf die Fragen von chris86 eingehe, möchte ich ein paar Punkte voranstellen list=1]
[*]Ich schätze die Arbeit und das Engagement der TAP-Entwickler und die Qualität des Supports in diesem Forum ungemein. Ich schreibe dies, damit evtl. im Weiteren als vielleicht unangemessen kritisch empfundene Kommentare relativiert werden können.
[*]Der "Movie Cutter" ist für mich kein "Killer-TAP", also keine unverzichtbare Funktion eines PVR. Wenn mir eine Aufnahme wirklich wichtig ist, ziehe ich sie mir auf meinen Rechner und schneide sie dort; ein komfortabler Export von Aufnahmen ist dabei sehr wohl unverzichtbar. Ich bin somit nur in Grenzen bereit, Komforteinschränkungen in Kauf zu nehmen um am Topf schneiden zu können; mehr dazu weiter unten.
[*]Unter diesen beiden Aspekten versuche ich mein Bestes daran mitzuhelfen eine komfortable Schnittfunktion bereitzustellen.
[/list]

Nun zu den Fragen:

1. Kannst du dich noch an die Reihenfolge erinnern, in der du geschnitten hast?
   Trifft es zu, dass die 4 verschwundenen Aufnahmen genau diejenigen waren, die du zuletzt geschnitten hast? Oder ist unter den verschwundenen Aufnahmen eine dabei, die vor einer anderen geschnitten wurde, welche aber erhalten geblieben ist?

Ich habe mir nochmal die TAPSytem.log angeschaut um meine Erinnerung aufzufrischen. Benennen wir die 7 Aufnahmen von 1 bis 7. Nach dem Schneiden meldet RbN "Corrected file time stamp of": 2, 3, 7, 6, 1, 4, 5 in dieser Reihefolge. Nach dem Reboot mit Festplattenüberprüfung waren 2, 3, 7 und 6, also die ersten vier der RbN-Aufzählung verschwunden.

Um noch auf die Frage von Töppi einzugehen:

waren das Dritte Sender der ARD wie zB. SWR?

Alle 7 Aufnahmen waren von "Das Erste HD" und "ZDF HD".

1. Warum hast du denn nach dieser Schnitt-Aktion nicht mal einen HDD-Check durchgeführt?
   Das hätte maximal 2 min gedauert, und deine Aufnahmen könnten (wahrscheinlich) noch leben...
   Außerdem wäre es für mich äußerst wichtig herauszufinden, ob der HDD-Check wirklich immer zuverlässig vor dem drohenden Aufnahmenfresser warnt. Und da du der einzige bist, der diesen derzeit produziert, wäre das ein wertvoller Test gewesen...
   (PS: Die Frage ist nicht böse gemeint, und erwartet auch keine Antwort^^ - aber es wäre ganz insbesondere in deinem Fall äußerst ratsam, wenn du das künftig tun würdest...)

Hier gilt was ich oben unter 2. dargestellt habe: Für eine für mich nicht unverzichtbare PVR-Funktion ist ein anschließender fsck eine zu starke Komforteinschränkung. Ich bin bereit bei einer Fehlersuche solche Prüfungen durchzuführen, und das habe ich auch wie berichtet bei früheren Tests getan. Das kann aber keine generelle "Feature" sein. Eine Schnittfunktion, die man mit einem fsck abschließen muss ist nur bedingt "brauchbar", weil unergonomisch. Dazu kommt das "zweischneidige Schwert" eines fsck bei einem gemounteten Filesystem. Ich halte den fsck für einen "Hack" und keine Lösung.

Ich werde aber trotzdem auf Deinen Vorschlag eingehen, nach dem letzten Schnitt einen fsck durchzuführen um weitere Erkenntnisse zu gewinnen.

1. Eine wichtige Frage von mir hast du immernoch nicht beantwortet:
   Hast du jemals ein Firmware-Update durchgeführt und danach eine alte Settings-Datei eingespielt?
   Und falls ja: Hast du danach deine Settings einmal auf die Werkseinstellungen zurückgesetzt, neu gestartet, und dann geschnitten, ohne zuvor eine Settings-Datei einzuspielen?
   Das wäre ein (sehr einfach zu behebender) möglicher Grund. Und das würde ich wirklich gerne als Verursacher ausschließen können.

Weder habe ich bisher nach einem Firmware-Update auf die Werkseinstellungen zurückgesetzt, noch habe ich jemals was mit Settings-Dateien getan. Gerade gestern habe ich die Firmware 1.03.02 vom 07.02.2014 für den CRP eingespielt, zusammen mit SE 6.1 und "IgnoreToppyPadding=1". Danach musste die Menu-Einträge wieder neu setzen, das waren evtl. schon Werkseinstellungen. Die Senderliste war aber nach dem Firmware-Update noch vorhanden.

Auch wenn das nichts mit MC zu tun hat, würde mich interessieren, weshalb RbN hier fehlschlägt.
-> Hast du mal probiert, ob sich die Aufnahmen überhaupt abspielen lassen?
-> Könntest du diese 3 Aufnahmen einmal mit einem Hex-Editor öffnen, und mir eine Kopie der ersten paar Kilobytes bzw. einen Screenshot der ersten Bildschirmseite zukommen lassen?

Die verbleibenden Aufnahmen lassen sich abspielen, aber nicht gescheit spulen und RbN versucht immer aus Neue die .nav zu rekonsturieren. Die Hex-Dumps mache ich später am Tag und schicke sie Dir per E-Mail.

Grüße
Herbert

[Roemer]

[quote="db1"]Interessant, dass nun auch Dateien verschwunden sind, die mit Mitteln der Firmware geschnitten wurden. [/quote]

Ich hatte das - glaube ich - schon einmal eingeworfen: ist es nicht so, dass MC ein Frontend zur Erzeugung einer Schnittliste ist? Die darin festgelegten Schnitte werden in einer Stapelverarbeitung "mit Mitteln der Fimware" durchgeführt.

Insofern wundert es nicht, dass Receiver mit "anfälligen" Festplatten auch mit dem systeminternen Schnitt Verluste aufweisen.

[FireBird]

[quote="Roemer"]Ich hatte das - glaube ich - schon einmal eingeworfen: ist es nicht so, dass MC ein Frontend zur Erzeugung einer Schnittliste ist?[/quote]
MC greift aber auf nicht öffentlich dokumentierte Firmware-Prozeduren zurück, deren Funktion durch reverse Engineering ermittelt wurden. Von daher lies sich natürlich nicht ausschließen, dass von MC Parameter an die Firmware übergeben werden, die diese so nicht erwartet hätte.

[Wolfman]

pöse doofe Firmware

[chris86]

Wer oder was hier gelöscht hat ...

Genau darüber könnte die TAPSystem.log Aufschluss geben. Vielleicht kannst du uns die Datei ja mal zur Verfügung stellen. (Am besten mit Hinweis, welche Aufnahmen du konkret vermisst...)

Wenn mir eine Aufnahme wirklich wichtig ist, ziehe ich sie mir auf meinen Rechner und schneide sie dort; ein komfortabler Export von Aufnahmen ist dabei sehr wohl unverzichtbar. Ich bin somit nur in Grenzen bereit, Komforteinschränkungen in Kauf zu nehmen um am Topf schneiden zu können; mehr dazu weiter unten.

Okay, das erklärt, warum du deinen Topf nicht längst aus dem Fenster geschmissen hast, wenn er dir ständig deine wertvollsten Aufnahmen löscht

Hier gilt was ich oben unter 2. dargestellt habe: Für eine für mich nicht unverzichtbare PVR-Funktion ist ein anschließender fsck eine zu starke Komforteinschränkung. Ich bin bereit bei einer Fehlersuche solche Prüfungen durchzuführen, und das habe ich auch wie berichtet bei früheren Tests getan. Das kann aber keine generelle "Feature" sein. Eine Schnittfunktion, die man mit einem fsck abschließen muss ist nur bedingt "brauchbar", weil unergonomisch. Dazu kommt das "zweischneidige Schwert" eines fsck bei einem gemounteten Filesystem. Ich halte den fsck für einen "Hack" und keine Lösung.

Da stimme ich dir (fast) vollkommen zu!
Natürlich ist das fsck nicht als "Lösung" aller Probleme gedacht.

Aber: Wenn du ganze 7 Filme schneidest, und angenommen du brauchst nur 5 min pro Film. Dann hast du damit immerhin 35 min deiner Lebenszeit zugebracht. Jetzt im Anschluss ein fsck, der ganze 2 min dauert - dich aber dafür evtl. vor der Löschung dieser 7 Aufnahmen bewahrt, das würde ich wohl in Kauf nehmen ;-)

Mindestens genauso wichtig ist aber ein anderer Aspekt:
Bis auf einen einzigen Fall konnten wir den Aufnahmenfresser bisher immer nur dann feststellen, wenn es schon zu spät war. Es wäre sehr wertvoll, wenn man das Problem zuverlässig direkt nach dem Schnitt identifizieren könnte, um a.) seine Aufnahme zu retten und b.) weiteres Debugging durchführen zu können, das ggf. bei der Entwicklung eines "Workarounds" helfen könnte...
Was in dieser Hinsicht bei deinen 7 Schnitten zum Beispiel interessant gewesen wäre:
Ist das FS nach jedem der ersten 4 Schnitte einzeln kaputt gegangen? Oder ist es erst nach dem vierten so kaputtgegangen, dass gleich 4 Aufnahmen betroffen waren? Oder hat gar der 7. Schnitt dafür gesorgt, dass die ersten 4 Dateien korrumpiert wurden?

Insofern wundert es nicht, dass Receiver mit "anfälligen" Festplatten auch mit dem systeminternen Schnitt Verluste aufweisen.

Das ist trotzdem eine wertvolle Erkenntnis:
Bisher habe ich viel Zeit darauf verwendet, meine Version immer wieder mit der "alten" von Firebird zu vergleichen - mit welcher es die Probleme angeblich noch nicht gab.
Nun wissen wir, dass es nicht meine Änderungen sind, die das Problem verursacht haben, sondern die Hardware/Software/Festplatten-Konfiguration ganz bestimmter einzelner Receiver...

[Bernhard75045]

Hallo

Nachdem mein SRP nun doch stabil zu laufen scheint (Danke, Gerti & Topfield!) kommen nun auch nach und nach div. TAPs auf die Kiste.

Ich sammle auf meiner HD hauptsächlich Filme, die aber in aller Regel nach dem Anschauen wieder gelöscht werden. Um Platz zu sparen hab ich mir bereits auf meinem 5500er angewöhnt, stets Vor- und Nachlauf sowie die Werbepausen wegzuschneiden bzw. bei mehreren Filmen innerhalb einer Aufnahme, diese zu trennen.
Auf dem 5500er nutzte ich dafür (mittels Tap-Launcher) Cut-Ads und CutFile.
Da ich auch 3PG nutzte war es auch immer recht einfach, ggf. die EPG-Infos zu korrigieren.

Nach den ersten Versuchen mittels MovieCutter klappt das eigentlich auch recht gut. Muss sagen: tolles TAP.
Was mich etwas irritiert ist, dass nach dem Löschen der entsprechenden Segmente stets das Dateisystem überprüft wird und dies oft recht lange dauert; eine Minute und mehr ist keine Seltenheit. Auch damit kann ich eigentlich gut leben (hat ja wohl seinen Sinn, diese Prüfung).
Was mir dann aber nicht so gefällt ist die Fehlermeldung, die immer wieder erscheint: "Dateisystem in.....(stabil? Genauen Wortlaut weiß ich grad nicht mehr). Aufnahme vor dem Ausschalten sichern."
Vielleicht sehe ich den Wald grad vor lauter Bäumen nicht, aber was ist mit dem "Sichern" an dieser Stelle gemeint?

Eine zweite Sache:
ich hab MC mittels der Ini so konfiguriert, dass ich es stets manuell aufrufen muss. (Sonst irritiert das meine Frau, wenn sie mal eine Wiedergabe startet.)
Aufgerufen wird mit der weißen Schnitt-Taste.
Soweit, sogut.

Wenn ich nun eine Aufnahme eines öffentlich-Rechtlichen-Senders hab ginge das Schneiden dennoch deutlich schneller ohne MC, denn hier muss ja nur Vor- und nachlauf entfernt werden. Wenn ich also nur den Verlaufsbalken einblende und im rechten Moment (eigentlich) die Schnitt-Taste drücke, das ungewünschte Stück markiere und mittels der blauen Taste lösche.
(das erspart mir zumindest die Zeit für das Überprüfen des Dateisystems)
Leider klappt das so natürlich nicht, weil ich mit der weißen Schnitt-Taste nicht die Schnittmarkierung setze sondern MC aufgerufen wird.

Gibt's da eine Lösung?

Sorry, falls das alles schon mal irgendwo durchgekaut wurde, aber den ganzen langen Thread wollte ich einfach nicht durchsuchen...

Ach ja, hier mal meine ini:

AutoOSDPolicy=0
DirectSegmentsCut=0
SaveCutBak=1
ShowRebootMessage=1
CheckFSAfterCut=1

[chris86]

Hallo Bernhard,

ich beantworte deinen Beitrag später nochmal ausführlich. (Bin grad in Eile...)

Wiederholte Warnungen bzgl. inkonsistentem Dateisystem sind aber eher nicht so gut! Das können zwar Fehlalarme sein (kommt leider öfters vor und lässt sich nicht vermeiden), kann aber auch auf ein gravierendes Problem hindeuten.

Kannst du dich bitte einmal per FTP auf deinen Topf verbinden, und mir aus dem Verzeichnis "ProgramFiles/Settings/MovieCutter" die Dateien "fsck.log" und "MovieCutter.log" zukommen lassen? (kannst du entweder hier im Forum einfügen oder mir per Mail senden).

[Bernhard75045]

Klar.

Die ".log" anbei als zip-Datei, da so lang.

Diie ".ing" (jedenfalls den Anfang) hier:

# To add a new language, copy a block and translate it
# the following codes are supported:
#
# LAN_Arab ar
# LAN_Czech cs
# LAN_Danish da
# LAN_Dutch nl
# LAN_English en
# LAN_French fr
# LAN_German de
# LAN_Greek el
# LAN_Italy it
# LAN_Norwegian no
# LAN_Persian fa
# LAN_Polish pl
# LAN_Russian ru
# LAN_Slovak sk
# LAN_Spain es
# LAN_Suomi fi
# LAN_Swedish sv
# LAN_Thai th
# LAN_Turk tr


#Deutsch
de_000= Neu
de_001= Löschen
de_002=Beenden
de_003= Verschieben
de_004=Pause/Menü
de_005= Auswählen
de_006=Keine nav-Datei! Zeitangaben evtl. ungenau.\nTrotzdem fortfahren?
de_007=Ausgewählte Segmente löschen
de_008=Diese Datei löschen
de_009=MovieCutter beenden
de_010=Konnte F/W-Funktion _bookmarkTime nicht finden.
de_011=Nächster Bookmark
de_012=Vorhergehender Bookmark
de_013=Importiere Bookmarks
de_014=OK
de_015=Vor-/Nachlauf entfernen
de_016=Ausgewählte Segmente speichern
de_017=Segmente
de_018=― Funktion auswählen ―
de_019=Der Schnitt ist fehlgeschlagen!\nBitte das Log prüfen!
de_020=Die Aufnahme ist (teilweise) verschlüsselt.
de_021=Schneide Aufnahme...
de_022=Ungerade Segmente löschen
de_023=Gerade Segmente löschen
de_024=Ausgewählte %u Segmente speichern
de_025=Ausgewähltes Segment speichern
de_026=Aktuelles Segment speichern
de_027=Ausgewählte %u Segmente löschen
de_028=Ausgewähltes Segment löschen
de_029=Aktuelles Segment löschen
de_030=Ungerade Segmente markieren
de_031=Vor-/Nachlauf markieren
de_032=Gerade Segmente markieren
de_033=Mittelstück markieren
de_034=Alle abwählen
de_035=Segmentliste zurücksetzen
de_036=Alle Bookmarks löschen
de_037=Export Segmente zu Bookmarks
de_038=Segmente
de_039=Bookmarks
de_040=Seite
de_041=Anfang
de_042= Ende
de_043=Sind Sie sicher?
de_044=Ja
de_045=Nein
de_046=Liste der Segment-Marker ist voll.
de_047=Aufnahme-Datei nicht gefunden.
de_048=HD-Video Erkennung fehlgeschlagen.
de_049=Die .nav-Datei konnte nicht geladen werden.
de_050=Länge der .nav weicht um %d sek. ab.\nTrotzdem fortfahren?
de_051=Receiver vor dem Schneiden neu starten!\nTrotzdem fortfahren?
de_052=.nav-Datei scheint inkorrekt. Repariert!\nWird erneut geladen...
de_053=Dateisystem überprüfen
de_054=Dateisystem wird geprüft...
de_055=WARNUNG! Dateisystem inkonsistent.\nAufnahme vor dem Ausschalten sichern!
de_056=Prüfung des Dateisystems abgebrochen.
de_057=Dateisystem scheint einwandfrei.
de_058=Dateiname oder -pfad ist zu lang!


#English
en_000= Add
en_001= Delete
en_002= Exit
en_003= Move
en_004= Pause/Menu
en_005= Select
en_006=No nav-file! Showed times may be inaccurate.\nProceed anyways?
en_007=Delete the selected segments
en_008=Delete this file
en_009=Exit MovieCutter
en_010=Failed to resolve f/w variable _bookmarkTime.
en_011=Goto next bookmark
en_012=Goto prev. bookmark
en_013=Import bookmarks
en_014=OK
en_015=Remove padding
en_016=Save the selected segments
en_017=Segments
en_018=― Select a function ―
en_019=The cut has failed!\nplease check the log!
en_020=The file is (partly) crypted.
en_021=Cutting recoding...
en_022=Delete odd segments
en_023=Delete even segments
en_024=Save the selected %u segments
en_025=Save the selected segment
en_026=Save the current segment
en_027=Delete the selected %u segments
en_028=Delete the selected segment
en_029=Delete the current segment
en_030=Select odd segments
en_031=Select padding
en_032=Select even segments
en_033=Select middle
en_034=Unselect all
en_035=Clear segment list
en_036=Delete all bookmarks
en_037=Export segments to bookmarks
en_038=Segments
en_039=Bookmarks
en_040=page
en_041=Begin
en_042= End
en_043=Are you sure?
en_044=Yes
en_045=No
en_046=SegmentMarker list is full.
en_047=Rec file size is incorrect.
en_048=HD-video detection failed.
en_049=Error loading the .nav file.
en_050=.nav length is %d sec. off.\nProceed anyways?
en_051=Please reboot the receiver before cutting!\nProceed anyways?
en_052=.nav duration mismatch. Patched!\nWill try again...
en_053=File system check
en_054=Checking file system...
en_055=WARNING! File system is inconsistent.\nBackup recording before power-off!
en_056=File system check aborted.
en_057=File system seems valid.
en_058=File name or path is too long!

[FireBird]

Es sollte noch eine "fsck.log" existieren. Die von Dir gepostete .lng (Language, nicht Ingenieur ) wird mit dem TAP geliefert.

[Wolfman]

bai se wey: das Checken lässt sich, wenn ich die ini richtig lese auch abschalten (den FSCheck Parameter auf 0 setzen. (was ich nicht weiß, macht... :und_weg

[Bernhard75045]

Es sollte noch eine "fsck.log" existieren. Die von Dir gepostete .lng (Language, nicht Ingenieur ) wird mit dem TAP geliefert.

ops:

Aber eine fsck.log find ich nicht

bai se wey: das Checken lässt sich, wenn ich die ini richtig lese auch abschalten (den FSCheck Parameter auf 0 setzen. (was ich nicht weiß, macht... :und_weg

Auf die Idee bin ich auch schon gekommen, aber ich gehe ja mal davon aus, dass das Checken durchaus seine Berechtigung hat...

[Wolfman]

Naja.... das erinnert mich an Fehlalarme von Virenschutzprogrammen mit anschließendem format C: