Kleinere Fehler bzw. Ungereimtheiten

[Elle4u]

Ich sehe gerade im Code, dass nach inode und nicht nach Dateinamen gesucht wird. Man müsste also einerseits nach der bei der Aufnahme geloggten inode suchen

OK. Schaue ich morgen mal.

[str1007]

wie setzt du die manuellen timer?

Das ist immer noch der allererste Timer, den ich gesetzt habe. Damals hatte ich noch gar kein TAP laufen und SE gab es noch nicht...
Ich bin mir aber nicht mehr sicher, ob ich den irgendwann durch Inkonsistenzen innerhalb SE nochmal löschen und neu anlegen musste, müsste dann aber schon ewig her sein.

Ich gehe davon aus, dass da die Funktion "Verlorene Events" zuschlägt.
Versuche doch mal im Menü von SE diesen Menüpunkt umzustellen auf "trotzdem aufnehmen" (oder ähnlich). Sehr wahrscheinlich steht das auf "löschen".

Der Menüpunkt steht seit Beginn auf "Trotzdem aufnehmen" (Datenverlust-Paranoia). Ein geblockter Timer wird damit aber auch nicht ausgeführt, was ja genau richtig ist. Ein Event kann nur "verloren gehen" wenn der zugehörige Suchauftrag (!) das nach einem erneuten Scan nicht mehr zuordnen kann. Ohne Suche kein verlorenes Event.

[Twilight]

Das ist immer noch der allererste Timer, den ich gesetzt habe. Damals hatte ich noch gar kein TAP laufen und SE gab es noch nicht...
Ich bin mir aber nicht mehr sicher, ob ich den irgendwann durch Inkonsistenzen innerhalb SE nochmal löschen und neu anlegen musste, müsste dann aber schon ewig her sein.

bist ganz schön hartnäckig

Der Menüpunkt steht seit Beginn auf "Trotzdem aufnehmen" (Datenverlust-Paranoia). Ein geblockter Timer wird damit aber auch nicht ausgeführt, was ja genau richtig ist. Ein Event kann nur "verloren gehen" wenn der zugehörige Suchauftrag (!) das nach einem erneuten Scan nicht mehr zuordnen kann. Ohne Suche kein verlorenes Event.

klar, mit lost events hat das nichts zu tun.
immer wieder kehrende timer sind für se auch nicht leicht zu händeln....auch gibt es berichte das solche timer verschwinden können bzw. wenn man ein falscher zeitstempel empfangen wird er sowieso unwirksam wird.
aus diesem gründen wird in se empfohlen suchtimer zu nutzen, speziell für immer wieder kehrende events. es gibt auch wirklich keinen grund das du das in diesem fall anders handhabst....
ich setze deine meldung gerne auf unsere bug liste, wann und ob das gefixt weren kann kann ich dir allerdings nicht sagen.

es wäre vorher aber nochmal zu prüfen was passiert wenn du den timer löscht und komplett neu anlegst.


twilight

[str1007]

OK, werde ich mal prüfen

[Elle4u]

Hi Alex!

Ich sehe gerade im Code, dass nach inode und nicht nach Dateinamen gesucht wird. Man müsste also einerseits nach der bei der Aufnahme geloggten inode suchen

Code: Alles auswählen

FileDB: new file  037 [color=blue]000000000000101a[/color] '/mnt/hd/DataFiles/RTL Aktuell - 2012-08-06 18-45.rec'

(das Blaue von Hex in Dezimal umrechnen), und andererseits mittels Telnet nachsehen, welche inode die rec hat.

Also ich sehe per Telnet folgendes:

Code: Alles auswählen

   4109 -rw-rw-rw-    1 root     root    1020170176 Aug  5  2012 RTL Aktuell - 012-08-05 18-45.rec
   [color=blue]4122[/color] -rw-rw-rw-    1 root     root    1010348544 Aug  6  2012 RTL Aktuell - 012-08-06 18-45.rec

Und 101a ergibt auch 4122... Und nun???

[FireBird]

Geht es nicht um den 5.8.? 6.8. wird doch erst heute gelöscht?

[Elle4u]

Geht es nicht um den 5.8.? 6.8. wird doch erst heute gelöscht?

Naja. Ich hatte das von Dir Zitierte genommen und die Aufnahme müsste ja auch schon weg sein (18 Stunden)

Aber hier der 5.08.

Code: Alles auswählen

2012-08-05 18:45:05 FileDB: new file  028 [color=blue]000000000000100d[/color] '/mnt/hd/DataFiles/RTL Aktuell - 2012-08-05 18-45.rec'

Code: Alles auswählen

   [color=blue]4109[/color] -rw-rw-rw-    1 root     root    1020170176 Aug  5  2012 RTL Aktuell - 012-08-05 18-45.rec
   4122 -rw-rw-rw-    1 root     root    1010348544 Aug  6  2012 RTL Aktuell - 012-08-06 18-45.rec

100d = 4109

Selbes Ergebnis.

[FireBird]

Dann weiß ich auch nicht, was bei Dir schief läuft.

[Elle4u]

[quote="FireBird"]Dann weiß ich auch nicht, was bei Dir schief läuft.[/quote]

beruhigen tut mich das jetzt nicht...

[str1007]

[quote="Twilight"]es wäre vorher aber nochmal zu prüfen was passiert wenn du den timer löscht und komplett neu anlegst.[/quote]

So, den manuellen täglichen Tagesschau-Timer habe ich gelöscht und neu angelegt: In der Sicht 3 zweimal auf Aufnahme gedrückt und den Typ auf täglich angepasst. Außerdem den Vor- und Nachlauf angepasst, der stand nämlich auf 0/0, obwohl in den SE-Settings -5/+10 eingestellt ist.

Vorgestern habe ich die laufende Aufnahme zeitversetzt angesehen; anschließend war der Timer nicht geblockt.
Gestern hat der Topf nach der Aufnahme automatisch abgeschaltet und ich habe mir die Aufnahme später angesehen. Und der Timer war wieder geblockt!

Im System.log habe ich keine relevanten Einträge gefunden, weder vom Timer anlegen noch vom Blocken. Daher poste ich das Log jetzt hier nicht. Soll ich noch was testen oder irgendwelche Indizien liefern?

[Twilight]

du kannst ein backup machen und mir schicken, mit den relevanten daten (timername usw.)

email gibts bei mir nur per pn.

twilight

[gerd.schmidt]

Hallo,

ich bringe wieder einmal das Problem der Doppelaufzeichnungen auf's Tablett. Darüber ist in diesem Thread schon einiges geschrieben worden, ohne dass es eine Lösung gegeben hätte. Deshalb meine Biite an die Experten, sich dieses Themas anzunehmen.

Wie unübersichtlich das werden kann, zeigt die angehängte Grafik. Da kann man schon einmal eine Datei aus Versehen löschen. Die Crux dabei ist, dass sich der Fehler nicht eingrenzen lässt. Er ist weder auf bestimmte Sendungen noch auf bestimmte Sender begrenzt. Es gibt nur ein festes Kriterium: Zu Doppelaufnahmen kommt es nur dann, wenn sich zwei (oder mehr) Sendungen senderunabhängig aneiander anschließen. Dann wird - allerdings nicht immer - die zweite und ggf weitere Sendungen doppelt aufgezeichnet.

Und es gibt ein weiteres Kriterium: Das Problem tritt erst seit Version 3 auf. Hier gab es erstmals Doppelaufzeichnungen. Zuerst dachte man an ein lokales Problem. Als es aber auch nach einer Neu-Installation von SE weiterhin Doppelaufzeichnungen gab, ging ich auf V2.9 zurück. Seither war wochenlang Ruhe. In der Hoffnung, unter V3.1 wäre dies jetzt ebenso, habe ich zu Beginn dieser Woche ein Update auf diese Version gemacht. Und prompt waren auch die Doppelaufzeichnungen wieder da. Vielleicht ist dies ein Ansatz für die Experten.

Entsprechende Logs sind beigefügt, allerdings begrenzt auf den 09.08.2012.

Gerd

[Ricki]

also ich habe diese Probleme nicht (auf beiden Töpfen nicht). Daher gehe ich davon aus, dass es an der Definition der Suche liegt. Ich suche nur an den Tagen und auf den Sendern, wo die Sendungen laufen, und gebe auch noch ein Zeitfenster vor.

[gerd.schmidt]

Ich kann mir nicht vorstellen, dass es an der Definition der Suche liegt. Zum einen sieht sie so aus wie bei dir (allerdings ohne Vor- und Nachlauf), zum anderen definiere ich alle Suchen gleich, also müsste das Problem grundsätzlich auftreten, was es aber nicht tut. Hinzu kommt, dass ich die Suchaufträge beim Up- oder Downgrade unverändert übernehme, und bei Version 2.9 gibt es diese Doppelaufnahmen definitiv nicht.

Gerd

[FireBird]

Welchen Vor- bzw. Nachlauf hast Du im Topf-Menü eingestellt (Einstellungen - Aufnahmen)?

[gerd.schmidt]

Einstellungen im Topf-Menü: 0/0

Gerd

[Ricki]

Der Vor- und Nachlauf am Topf ist OK.
Hast Du sicher den Aufnahmemodus in SE auf "Alles"?

[strotti]

Ursprungstext war ein Irrtum

Strotti

[Maliboy]

Ich kann mich Rikki nur anschließen. Ich hatte noch NIE doppelte Aufnahmen. Ich bin aber öfter überrascht, was manche M-Timer doch zum Vorschein bringen.

[gerd.schmidt]

[quote="Ricki"]Der Vor- und Nachlauf am Topf ist OK.
Hast Du sicher den Aufnahmemodus in SE auf "Alles"?[/quote]

Ja, das habe ich.

[quote="Maliboy"]Ich bin aber öfter überrascht, was manche M-Timer doch zum Vorschein bringen.[/quote]

Was meinst du damit? "M-Timer erzeugen" steht bei mir auf "Ja".

Gerd