Feuervogel,

es gehört ja eigentlich nicht mehr in dieses Thema...

Du musst die Liste aufrufen (nicht den Film stoppen). Das macht man üblicherweise (wie beim TV schauen), also z.B. mit UP oder DOWN Taste. Dann hast du die Liste und der Film läuft noch. Je nach dem, welches Plugin du installiert hast oder welchen Skin du benutzt, findest du dort die 4 Farbtasten, ROT ist i.a. mit Löschen belegt. Sieht z.B. so aus...

Hi Feuervogel,

"normal" geht das über mehrere Tasten, in der Liste -> Menü-Taste -> Löschen auswählen...
Einfach geht es in der Liste mit Taste ROT (wenn man EMC benutzt oder movieselectionquickbutton, danke Fred Bogus Trumper) nur eine Taste

Gruß
Anne

Hallo Reichi,

oh, das wäre ja prima! Danke für die schnelle Antwort.

lg
Anne

Hallo und zunächst Danke an euch alle für die Ratschläge.

Natürlich kann man mit STOP die Wiedergabe beenden und dann den Film löschen. Das war aber nicht die Frage. Bisher konnte man im OE1.6 einen LAUFENDEN Film direkt löschen ohne vorher mit der Stop-Taste die Wiedergabe beenden zu müssen. Wenn man im OE2.0 einen LAUFENDEN Film löscht, läuft dieser aber weiter bis man mit Lame die Filmliste wieder verlässt. Dass ein angeblich gelöschter Film einfach weiterläuft, ist schon etwas seltsam.

Ich möchte an den von euch beschriebenen Varianten nichts verändert haben, das soll doch alles so bleiben. Es wäre trotzdem schön, wenn (so wie vorher) ein Film nach der Löschbestätigung auch sofort gelöscht wird (oder je nach Einstellung in den Papierkorb geht) und damit automatisch auf TV zurückgeschaltet wird ohne dass man die Wiedergabe vorher mit STOP beenden muss.

Grüße
Anne

Hi arki,

da hast du mich falsch verstanden. Die Wiedergabe soll nicht stoppen, wenn die Liste aufgerufen wird, sondern wenn der Film gelöscht wird. Ich kann keinen Sinn darin erkennen, dass ein gelöschter Film weiterläuft.

Gruß
Anne

Hallo,

wenn man bei laufender Filmwiedergabe die Movieliste aufruft (Up, Down) und den laufenden Film löscht (über Menü), dann läuft das Video trotzdem weiter. Im OE1.6 wurde beim Löschen die Wiedergabe automatisch gestoppt und auf TV geschaltet (so wie es sein soll).

Kann man das wieder ändern? Danke.

Gruß
Anne

Hallo Ghost,

zunächst vielen Dank für deine Antwort.

Wenn es sich um Laufschrift oder schnell fliegenden Fußball usw. handeln würde und dabei Ruckeln o.ä. auftreten würde, könnte ich das verstehen. Da hat der Deinterlacer was zu tun, da muss er richtig "hart arbeiten". Da wird man sicher auch immer wieder Verbesserungen bei den Verfahren finden...

Aber bei einem Standbild? Sollten da nicht beide "Halbbilder" nahezu identisch sein und man braucht sie nur noch zusammenzusetzen? Wenn bei diesem "Zusammensetzen" Bildpunkte so weit "verschoben" werden, dass aus geraden Linien ziemlich grobe Zacken werden, dann ist das doch ein Fehler?

Ich soll mir ja keine großen Hoffnungen machen, vielleicht könnt ihr trotzdem was machen (oder machen lassen).

Anne

Hallo Eberhart,

ich bin kein Jurist, ob Mangel der richtige Ausdruck ist, weiß ich nicht (und es ist mir auch egal, es geht um die Sache und nicht um Formulierungen).

Ich habe für die Box 1000 € bezahlt. Wenn man mir dann sagt, ich solle für einen besseren Interlacer noch mehr hinblättern, bin ich schon etwas überrascht. Schließlich haben weitaus günstigere Boxen dieses Problem nicht (getestet an einem Open Source PVR).

Außerdem dachte ich bisher, dass DMM an unseren Rückmeldungen zur Verbesserung ihrer Produkte interessiert wäre. Um das o.g. Problem auch gut beschreiben und geeignetes Filmmaterial zur Verifizierung zu bekommen, habe ich viele Monate Aufnahmen gesammelt und zurecht geschnitten und nun endlich einen aussagekräftigen Filmschnipsel bekommen. Da kann sich jeder diesen Zacken-Bug ansehen und die Programmierer können gezielt diesen Fehler beheben. Es geht eben nicht darum, ein mathematisches Verfahren für den Deinterlacer weiter zu entwickeln, sondern einen Programmfehler zu beseitigen (ganz gleich, ob DMM daran "Schuld" hat oder ein Zulieferer).

lg Anne

Hallo,

zunächst Danke an WilliamG für die Info aber ich hätte schon
eine Antwort von DMM erwartet.

Selbst wenn hier "Zulieferteile" die Ursache des
Fehlers sind, die Box habe ich für sehr viel Geld in einem Stück gekauft, daher
ist der Hersteller auch dafür verantwortlich, die Mängelbeseitigung bei seinen
Partnern anzumahnen.

Anne

Hallo,

trotz eigentlich sehr guter Bildqualität kommt es immer wieder vor, dass glatte Kanten "gezackt" aussehen. Besonders auffällig ist das bei Schrift.

Nachdem ich dieses Phänomen lange Zeit beobachtet und Material dazu gesammelt habe, konnte ich kürzlich eine äußerst geeignete Aufnahme des Problems machen.

Bildbeschreibung: Mann links und Frau rechts halten eine Tafel mit fast gleichem Schriftzug. In der ersten Kameraeinstellungen ist die Schrift links in Ordnung, gleichzeitig der rechte Schriftzug gezackt. (sh. Bild -> screenshot.jpg oder ts -> 20130407_1658_-_VOX_-_AUTO_MOBIL.zip)

Schaltet man den Deinterlacer von automatisch auf bestmöglich sind die Zacken weg (dann ist die Bildqualität natürlich nicht mehr so gut wie mit der Automatik).

Kann man diesen Bug beheben?

Gruß

Anne

Box: DM 8000

Release 3.2.4 vom 04.11.2012

Diesmal hat es einen täglichen Timer erwischt (screenshot-2010-11-24.jpg und timers2010-11-24a.xml). Die Anfangszeit wurde nicht korrekt ermittelt, da hätte der darauf folgende Tag 19:27 stehen müssen. Habe ich manuell korrigiert (timers2010-11-24b.xml).

Kann das Problem keiner lösen?

Gruß

Anne

TheDOC,

im Anhang die timers2010-11-01a.xml (18:55). Der Eintrag "Lindenstraße" ist jetzt richtigerweise an letzter Stelle zu finden. Jedoch ist eine Woche zuviel auf das Anfangsdatum addiert worden (da hätte der 7.Nov. stehen müssen und nicht der 14.Nov.).

Der nächste wöchentliche Timer der gestern abend lief, war "Kreutzer". Ich habe nach der Aufnahme die Timerliste kontrolliert (23 Uhr, sh. screenshot-2010-11-01.jpg), der Eintrag ist auf die (vor)letzte Stelle gerückt (an letzter Stelle steht ja der falsche 14.Nov.-Eintrag). Soweit so gut. Als ich mir jedoch die Daten der letzten Einträge angesehen habe, war ich doch überrascht. Denn auf "Kreutzer" wurde keine Woche addiert, obwohl die Aufnahme gelaufen ist und der Eintrag an das Listenende gestellt worden ist. Somit sind die letzten 3 Timer:
Mentalist 8.Nov
Kreutzer 1.Nov. ???
Lindenstraße 14.Nov.
Diese Reihenfolge hätte doch nur gestimmt, wenn Kreutzer+1Woche-> 8.Nov. stehen würde.

Die zugehörige timers2010-11-01b.xml (also auch 23 Uhr gesichert) stimmt mit der am TV angezeigten nicht überein, hier ist Kreutzer noch an 1. Position zu finden (also als ob die Aufnahme noch nicht gelaufen wäre).

Gruß
Anne

Hallo TheDOC,

im Anhang die settings, ich habe 2 Sat-Tuner drin.

Gestern abend (Sonntag, 31.10.) gab es wieder diesen Fehler. Die Lindenstraße wurde korrekt aufgenommen, beim Errechnen der Daten für die nächste Woche ist jedoch nicht das richtige Ergebnis rausgekommen (sh. screenshot.jpg -> letzter Eintrag ganz unten).

Ich habe direkt mit der Box über "Einstellungen sichern" ein backup gemacht und die timers.xml (auch im Anhang) mitgeschickt. Obwohl das enigma2settingsbackup.tar.gz von 20:17 Uhr ist, ist die darin enthaltene timers.xml von 01:32 Uhr. Das liegt noch vor der Aufnahmezeit, da sind also alle Einträge noch richtig. Ich hatte gedacht, dass die Timerliste immer gleich nach einer Aufnahme aktualisiert wird, anscheinend ist das nicht der Fall. Ich kann heute abend die Liste nochmal sichern und sie dann morgen schicken...

Die timers.xml wird anscheinend auch immer neu geschrieben, wenn die Box aus dem Deep-Standby aufwacht (elektro-plugin). Anscheinend hatte meine Box in der Nacht die Zeit jedoch "vergessen" und das Datum dann auf den 01.01.2000 gesetzt (sh. Bild.jpg). Die Fehleinträge sind auch in der timers.xml zu finden (<log code="0" time="946684...). Da die Startzeiten der Timer dann trotzdem richtig sind (also Oktober 2010), nehme ich an, dass dieser Efekkt nichts mit den seltsamen Timerzeiten zu tun hat.
.

lg
Anne">

TheDOC,
hast Du schon was rausgefunden oder kann ich zur Fehlersuche noch etwas tun?
.
lg
Anne

Ich habe gestern noch ein wenig probiert, vielleicht hilft es bei der Lösung weiter...
.
Ich hatte nach dem crash letzte Woche (also die Dateien die ich schon geschickt habe) das mitloggen wieder abgeschaltet und die originale RecordTimer.py wieder draufgespielt. Zunächst lief alles prima, bis gestern abend wieder ein TimerEintrag mit Länge 0 zu finden war.
begin="1287174480" end="1287174481" ("heute-show" in timers2010-10-13a.xml)
Ich habe den Eintrag direkt an der Dreambox auf die richtige Endzeit gesetzt und das Mitloggen wieder eingeschaltet:
begin="1287174480" end="1287179100" (timers2010-10-13c.xml).
Dann habe ich Deine modifizierte RecordTimer.py installiert und sofort gab es einen crash (crash_1287007565.xml). Von den ursprünglich 21 TimerEinträgen waren über die Hälfte weg. Also das Verschwinden von Timern muss mit der abgeänderten RecordTimer.py und nachfolgendem crash zusammenhängen.
Wenn ich die crash-Datei richtig verstehe, sollte als letzte Aktion die völlig richtige Anfangszeit ("Navy CIS")
[TIMER] setting begin from: 1287363180 Mon Oct 18 02:53:00 2010
verändert werden (wieso? der 18.Okt. kommt doch erst noch).
Und beim Addieren von einer Woche kommt seltsamerweise nicht die gleiche Uhrzeit raus, sondern
[TIMER] to:1287957964 Mon Oct 25 00:06:04 2010
also nicht 02:53 Uhr, sondern 00:06 Uhr und 4 Sekunden.
Diese falsche Zeit wurde richtigerweise erkannt und der crash ausgelöst.
.
Also wieso wollte die Box bei einem wöchentlichen Timer, der noch nicht vorbei war, eine Woche addieren? Und wieso kommt dann eine falsche Zeit raus?
Hilft das oder wird es immer verwirrender???
lg
Anne

Ach der Lost-Jacob. Da stand ich wohl etwas auf der Leitung...
.

Ich habe ja von der ganzen Sache keine Ahnung aber in der crash-log stand doch was davon drin, dass ein Eintrag gefunden wurde, der nicht durch 60 teilbar ist. Mit der von Dir modifizierten RecordTimer.py wurde doch bewusst dieser Absturz hervorgerufen. Also kam der crash bevor die Lost-Einträge wieder zurück in die TimerListe geschrieben wurden und so waren die dann "verschwunden"?
Jedenfalls ist sowas bisher noch nie aufgetreten sondern erst mit der speziellen RecordTimer.py. Ich denke, wenn ich später wieder die originale Datei nehme, tritt das nicht mehr auf.
In der crash steht auch was von "ignore timer conflict" (kurz vor dem Eintrag mit der gleichen Start und Endzeit). Muss da nicht schon vorher was schief gelaufen sein, denn einen TimerKonflikt hätte es doch nicht geben dürfen. Und möglicherweise ist das Setzen der Anfangs- und Endzeit auf 22:14 das Resultat eines Fehlers der zuvor aufgetreten ist und diesen TimerKonflikt verursacht hat?
Alles nicht so einfach...
lg
Anne

Hallo TheDOC,
Jacob fragen? Du meinst damit, für mein Problem das falsche Forum?
Trotzdem vielen Dank für Deine Mühe!!!
lg
Anne

Hi,
also ich habe an der Timerliste nichts gemacht. Ich habe am Freitag Abend (08.10.) gesehen, dass es eine crash-log gibt. Die habe ich mir gesichert und die Timerliste ebenfalls. In der Liste selbst waren keine seltsamen Einträge. Da habe ich mich schon gewundert. Ich habe jedoch nicht bemerkt, dass Einträge völlig fehlen! Nur gut, dass Du mich darauf aufmerksam gemacht hast.
Im Anhang die Timer.xml vom 05.10. Da stehen die beiden verschwundenen Einträge noch drin:
"Lost" jeden Do 22:14 bis 23:21
und
"Lost" jeden Do 23:14 bis 00:16 (Fr)
Beide wöchentlichen Timer sind in der Timerliste nach dem crash (08.10.) einfach verschwunden. Wo sind die hin???
Gruß
Anne
PS: Ist eigentlich ganz lustig, dass ausgerechnet "Lost" weg ist

Hallo TheDOC,

nun hat es ziemlich lange gedauert aber jetzt ist so ein Fehler wieder aufgetreten.

3:58 (da wacht meine Box aus dem Deep-Standby auf) wurde versucht, eine Zeit in die Timeliste zu schreiben, die nicht durch 60 teilbar ist. Ich habe die Dateien angehängt. Kannst Du den Fehler jetzt finden? Das wäre prima!

Danke.

Gruß

Anne

Hi TheDOC,

gesten Abend gab es einen crash. Ob dieser in Zusammenhang mit dem Timer-Fehler steht, weiß ich jedoch nicht. Hoffentlich findest du jetzt die Ursache. Danke.

lg

Anne