ich unterstütze den Wunsch

Ich bitte auch dringend um diese Funktion

liebe grüsse
kurt

Ich denke mal, daß diese Funktionalität für alle ineressant wäre, die die Box nutzen wollen.

Wird aber sicher sehr komplex zu coden sein...

Yo ist halt das Problem bei den Tunertuner, bei Enigma1 ist die Sperre ja vorhanden.

Aber frage mich jetzt auch nicht was da schwer sein sollte. Man muss halt prüfen, wenn Tuner A für den zeitraum was aufnimmt, dann muss halt der Tuner gesperrt sein (ausser selbe Frequenz)

Hallo Zusammen,

Irgendwie faellt es mir schwer zu glauben das es nur wenige Leute gibt die dieses Feature dringend brauchen. Ich stolpere fast taeglich ueber dieses Problem. Es sollte auf der Liste der wichtigen Dinge weit oben stehen !!

Tron911

Ich bin ebenfalls Befürworter dieses Features.
Bei mir kommt erschwerend hinzu, dass ich 1x Sat- und 1x Kabeltuner verbaut habe. Da bin ich natürlich viel schneller an der Kapazitätsgrenze als beim Einsatz von 2 gleichen Tunern.
Würde eine Mitteilung kommen, dass sich 2 Timer überschneiden, könnte ich sofort darauf reagieren. So muss ich alles manuell nachkontrollieren und im schlimmsten Fall habe ich Tuner Failed.

Ich denke, diverse Cracks dürften schon nen Lösungsansatz im Kopf haben, oder etwa nicht ?

Gruss,
Digitangel

Hi,

Das beste ist ja noch das wohl der Programmteil der die Ueberpruefung machen soll immer den WERT "passt schon" zurueck liefert

Leider habe ich ja von der ganzen DREAM_Programmiererei keine Ahnung sonst wuerd ich hier Tag und Nacht am basteln sein

Tron911

P.S:

guckst Du hier ...

/usr/lib/enigma2/python/Components/TimerSanityCheck.py 


         def checkRecordable(self, timerlist):
		# TODO: Add code here
		return True

Ich habe die 7025CC zwar erst seit Anfang März, aber habe schon etliche Jahrzehnte Erfahrung mit der Programmierung von Timern. Die 7025 ist das 1. Gerät, dass nicht merkt, wenn bei der Programmierung Timer kollidieren. Und ja, auch moderne Twin-PVRs der Konkurrenz beherrschen das mühelos. Das ist sehr schwach und mich wundert es wirklich, dass sich da nichts tut.

Das Problem ist aber auch nicht soo einfach zu loesen.

Man sollte immer im Hinterkopf behalten, dass es sich bei Enigma2
NICHT um ein System handelt, dass NUR fuer ZWEI Tuner fuer nur
EIN Empfangssystem geschrieben wurde.
Prinzipiell kann es mit beliebig vielen Tunern fuer unterschiedliche
Empfangssysteme (DVB-S,-C und -T) umgehen (in der 8000er
dann mit vier). Und bei SAT muss noch beruecksichtigt werden,
dass die Schuessel beweglich sein kann (Rotor) und damit eine
weitere Komplexitaetsstufe hinzukommt.
Nur ein Ignorant von kommerziellen Interessen wuerde jetzt sagen:
"Dann macht doch erstmal eine Loesung fuer die Leute, die nur
eine Art von Tunern auf einer festen Schuessel betreiben, da das
doch die Mehrheit der Benutzer sind. Um die anderen kuemmert
ihr euch spaeter."
Hmmm, was meinst Du, was "die paar" ausgeschlossenen Benutzer
dann Dream an den Kopf werfen wuerden? (Tip: es werden keine
Freundlichkeiten sein ;-)) ). Der daraus entstandene Thread im
Forum wuerde dann problemlos in wenigen Wochen die Anzahl an
Beitraegen jedes anderen Threads ueberbieten. :-))

Wenn man sich jetzt vorstellt, dass man jede beliebige Kombination
von Sat-, Kabel- und DVB-T-Tuner stecken kann und jeder Benutzer
eine eigene Vorstellung von Prioritaeten bei der Aufnahme hat,
neben live schauen auch noch Streaming beruecksichtigt werden
muss, kommt am Schluss ein sehr sehr komplexer Algorithmus heraus,
der auch noch einen gigantischen Test- und Wartungsaufwand
generiert; von der Masse an Fehlermeldungen von Benutzern, die die
Art und Weise der Implementierung dann nicht verstanden haben
und Features als Bugs melden, mal ganz abgesehen.

"Andere Anbieter" von Twin-PVRs haben meistens keine Geraete
im Angebot, die mit unterschiedlichen Tunern bestueckt werden
koennen. Eine Loesung nur fuer SAT oder nur fuer Kabel oder nur
fuer DVB-T ist da nicht ganz so schwer zu implementieren. Ob diese
Anbieter dann auch korrekt mit Rotor-betriebenen Schuesseln
umgehen, will ich mal ganz dahingestellt lassen (spielt hier auch keine
Rolle).

Wenn die 8000er rauskommt, habe ich mir vorgenommen, dieses
Problem selbst mal anzugehen, da es bei vier Tunern dann fuer mich
nicht mehr einfach moeglich ist, die Konflikte per "Okularinspektion"
zu erkennen. Allerdings kann ich es mir dann auch leisten, nur das
zu implementieren, was ich gerade brauche (und eine, auch nur
ansatzweise, Beruecksichtigung von Rotoren gehoert dann sicherlich
NICHT dazu).
Vermutlich hat Dream auch auf soetwas gehofft (das ein Nutzer
eine eigene Implementierung schreibt und veroeffentlicht und sie
den schwarzen Peter des Supports in den "Geburtswehen" der
Loesung weitergeben koennen und am Schluss nur noch eine
bestehende Loesung integrieren muessen ;-)) ).

Gruss

Zitat

Das Problem ist aber auch nicht soo einfach zu loesen.

Nur weil es nicht einfach ist, entschuldigt nicht, daß es nicht gemacht wurde.

Seit mehr als 15 Jahren erwartet man bei einem besseren Videorecorder, daß er Timerkollisionen erkennt. Okay, die meisten haben nur einen Tuner, es gab aber auch welche mit zwei (terrestrisch und SAT). Da hat man auch noch das zusätzliche und wirklich nicht lösbare Problem, daß die VPS Zeiten nicht immer mit den wirklichen Zeiten übereinstimmen müssen. Trotzdem muß (mußte) und wurde auf eine mögliche Kollision hingewiesen (auch mit dem Risiko das dieser Hinweis bei falschen VPS Zeiten unnütz war).

Heutzutage _muß_ einfach ein Aufnahmegerät der gehobenen (Preis-)Klasse Kollisionen erkennen und zumindest eine entsprechende Warnung anzeigen. In diesem Fall, besser eine Warnung zu viel, als eine zuwenig. Die Box zeigt sich ja auch sonst nicht so kommunikationsscheu (Ein Aufnahmetimer will ihre Box abschalten usw. obwohl ich doch selbst 20s davor per Remote einen Senderwechsel veranlasst habe .....)

Ich bin sicher während der Entwicklung einer High End Box wie der 7025 gab's eine Menge von 'nicht einfach lösbaren' Problemen. Dazu sind ja die Entwickler da, um Probleme zur Zufriedenheit der Kunden zu lösen (und ich weiß wovon ich spreche!). Die 7025er ist zwar eine High End Box mit vielen Features und Möglichkeiten und auch mit entsprechendem Preis, aber leider fehlt halt an einigen Ecken und Enden der nötige Feinschliff damit daraus wirklich ein Qualitätsprodukt auf höchsten Niveau wird. Das Traurige daran ist halt auch, daß einige der Schwachstellen schon so lange Zeit nicht ausgemerzt wurden.

Und es liegt nicht an mir als Kunden einen fertigen patch für einen Bug zu liefern. Es liegt am Hersteller ein Gerät zu liefern, welches die Funktionen bietet, welche ein üblicher Kunde an ein Gerät dieser Preisklasse stellt, dem Stand der Technik entsprechend. Diesen Satz bitte als allgemeine Aussage zu verstehen. Beim konkreten Punkt kann man ev. drüber streiten, ob das nun wirklich ein Bug ist, oder doch eher ein geringfügiger Mangel. Dream denkt offensichtlich es ist eher zweites.
----------------
Ich konnte leider meinen obigen Beitrag nicht ununterbrochen schreiben, deshalb ist Reichis Antwort dazwischengekommen -

Zitat

Schön fände ich auch, wenn sich mal jemand daran versucht Prioritäten efffizient zu implementieren, gerade bei einer DM8000 mit vier Tunern könnte das ein durchaus interessantes Feature sein Augenzwinkern

Ich glaube nicht, daß es wirklich notwendig ist, die Aufnahmen gleich zu priorisieren. Das sollte man besser dem Nutzer überlassen, der weiß besser welche Aufnahme nun wichtiger oder weniger wichtig ist. Die Warnung das bei einer aktuellen Timerprogrammierung was überlappt und ev. so nicht funktioniert ist doch mal vorerst das Wichtigste. Also z.B. drei Aufnahmen zur gleichen Zeit auf unterschiedlicher Frequenz aber nur 2 Tuner --> Warnung.

könnt man nicht eine Anzeigemöglichkeit schaffen in der auf einer Bildschirmseite alle sich jeweils überlappenden Timer mit Zeitstrahl dargestellt werden.

Und dann muss der User entscheiden ob er etwas ändert oder es so lässt weil seine 2 oder 4 oder x Tuner das verkraften.

Ein Hinweis in der Art "Timer x auf Transponder x kollidiert mit Timer y auf Transponder y" würde mir schon genügen. Da ich meine Tunerkonfiguration kenne, kann ich dann recht schnell entscheiden, ob das später wirklich kracht oder eben nicht. Da ich aber sehr oft unter Zeitdruck etliche Timer programmiere, ist das aktuell immer ein bißchen Timerlotto ...

Zitat

Original von Rafiki
Das Traurige daran ist halt auch, daß einige der Schwachstellen schon so lange Zeit nicht ausgemerzt wurden.

Diese Sicht ist Dein gutes Recht, da ich aber keine Kenntnisse ueber die
Manpower bei Dream habe, kann ich auch nicht beurteilen, woran es
liegt, dass es scheinbar so gelaufen ist. Die wahrscheinlichste Erklaerung
ist halt fehlende Manpower.
Falls Du tatsaechlich Erfahrungen mit professioneller Softwareentwicklung
haben solltest, weisst Du auch, dass die Tuecke im Detail liegt und die
alte Rechnung (die letzten 10 Prozent brauchen 90 Prozent der Zeit)
immer noch stimmt (besonders, wenn Hardware ins Spiel kommt).

Zitat

Original von Rafiki
Beim konkreten Punkt kann man ev. drüber streiten, ob das nun wirklich ein Bug ist, oder doch eher ein geringfügiger Mangel. Dream denkt offensichtlich es ist eher zweites.

Das ist jetzt aber Ansichtssache, ob man ein fehlendes Feature als Mangel
oder gar Bug bezeichnet.
Wenn das Feature zum Funtionieren unabdingbar ist, wuerde ich ja
zustimmen, aber man kann ja Aufnahmen Programmieren und die Box
entscheidet zum Aufnahmezeitpunkt, ob es auch geht (bzgl.
Konflikterkennung).
Eine nervige Meldung ala "es wurden mehr als eine Aufnahme zur
gleichen Zeit programmiert; es kann zu Kollisionen kommen" waere
zumindestens fuer mich eben nur das: "nervig".
Jede detailliertere Aussage in der Fehlermeldung fuehrt automatisch
zu der von mir kolportierten Komplexitaet (siehe "Rotor").

Zitat

Original von Rafiki
Die Warnung das bei einer aktuellen Timerprogrammierung was überlappt und ev. so nicht funktioniert ist doch mal vorerst das Wichtigste. Also z.B. drei Aufnahmen zur gleichen Zeit auf unterschiedlicher Frequenz aber nur 2 Tuner --> Warnung.

Und schon haben wir genau das, was ich in meinem Beitrag beschrieben
hatte: die halbgare Loesung mit nachgeschaltetem Supportaufwand.
Wenn jetzt ein Rotor ins Spiel kommt, kann bereits bei der ZWEITEN
Aufnahme, trotz zweier Tuner, eine Kollision auftreten (wegen der
moeglicherweise unterschiedlichen Satellitenposition der beiden
aufzuzeichnenden Transponder). Ein weiterer Stoplerpunkt ist die
Verschluesselung. Was ist, wenn nur ein Stream zur gleichen Zeit
entschluesselt werden kann? Das muesste die Box dann auch erkennen
und davor warnen. Damit sind auch Kenntnisse ueber ALLE Verfahren
zur Verschluesselung noetig, um eine korrekte Loesung zu bauen.
Irgendetwas zusammenzuhacken, was in 60 Prozent der Faelle etwas
sinnvolles tut, mag noch relativ leicht sein und in OpenSource-Kreisen
auch eine akzeptable "Loesung" sein, aber als Unternehmen sollte
man genau abwaegen, ob man sich den daraus entstehenden Frust der
Kunden wirklich leisten kann.
Dream hat offensichtlich entschieden, das Feature entweder richtig oder
garnicht zu implementieren (wobei ich hier nicht implizit behaupte, dass
sie dies auch in allen anderen Faellen so machen bzw. gemacht haben).

Es ist halt NICHT trivial.

Aber es bleibt Dir unbenommen, wenn Du auch weiterhin die Forderung
gegenueber Dream aufrecht erhaelst, dass eine Loesung bei einem
HighEnd Produkt eigentlich eine Selbstverstaendlichkeit sei.
Ich waere der Letzte, der sich nicht ueber eine komplette Loesung von
Dream freuen wuerde (muss ich selbst weniger machen).

Gruss

Zitat

Original von kenatonline
Diese Sicht ist Dein gutes Recht, da ich aber keine Kenntnisse ueber die
Manpower bei Dream habe, kann ich auch nicht beurteilen, woran es
liegt, dass es scheinbar so gelaufen ist. Die wahrscheinlichste Erklaerung
ist halt fehlende Manpower.
Falls Du tatsaechlich Erfahrungen mit professioneller Softwareentwicklung
haben solltest, weisst Du auch, dass die Tuecke im Detail liegt und die
alte Rechnung (die letzten 10 Prozent brauchen 90 Prozent der Zeit)
immer noch stimmt (besonders, wenn Hardware ins Spiel kommt).

Alles anzeigen

Und genau diese paar % bzw. die Liebe zum Detail machen den Unterschied zwischen 0815 und Qualitätsprodukt. Oder auch anders gesagt, zwischen Bastel- und Profilösung. Wobei die Grenze natürlich nicht digital ist und ich auch keinesfalls die Dream Produkte in die Bastelecke einreihen will. Übrigens, Hardware ist immer dabei. Ohne läuft keine SW

Zitat

Das ist jetzt aber Ansichtssache, ob man ein fehlendes Feature als Mangel oder gar Bug bezeichnet.

Klar, deshalb will ich das ja auch diskutieren. Eventuell bin ich ja der einzige der mit solchen 'Features' seit mehr als 15 Jahren von seinem VCR verwöhnt ist und es deshalb als 'Standard' voraussetzt.

Zitat

Eine nervige Meldung ala "es wurden mehr als eine Aufnahme zur
gleichen Zeit programmiert; es kann zu Kollisionen kommen" waere
zumindestens fuer mich eben nur das: "nervig".
Jede detailliertere Aussage in der Fehlermeldung fuehrt automatisch
zu der von mir kolportierten Komplexitaet (siehe "Rotor").

Es wäre in der Tat nervig, wenn die Box jedesmal so eine Meldung ausgeben würde ohne vorher zu überprüfen, ob 1 oder 2 Tuner für die entsprechende Übertragungsart verbaut sind, oder ob die zwei Sendung nicht ohnehin auf der gleichen Frequenz daherkommen usw. Aber, das alles 'weiß' die Box ja. Und beim Rotorbetrieb ist's genauso. Zwei Sendungen auf zwei verschiedenen Rotorpositionen können eben nicht gleichzeitig aufgenommen werden. Warum sollte das die Box nicht wissen? Klar ist sowas mit allen Eventualitäten nicht einfach mal in 5 Zeilen in der Mittagspause programmiert, aber das behauptet ja niemand. Und daß man dem User der die Schüssel händisch auf jeden Satelliten hin stellt keine perfekte Lösung liefern kann ist auch klar. Aber der beklagt sich dann ohnehin nicht über eine mißglückte Aufnahme.

Abgesehen davon muß man bei solchen Dingen schon ein bißchen pragmatisch sein. D.h. wieviele Prozent der Dream User nutzt ein Rotorsystem und soll man wegen der ev. 0,05% (geschätzt) den anderen 99,95% eine sinnvolle und notwendige Funktion vorenthalten? Entwicklungsarbeit besteht auch daraus Kompromisse zu schließen. Klarerweise kann Dream sagen, wir wollen hier keinen Kompromiss sondern nur eine 100%ige perfekte Lösung oder gar keine. Wenn das die Antwort ist, muß ich damit leben. Aber die Antwort in der Art - 'es ist alles sehr kompliziert' - stellt mich nicht zufrieden.

Zitat

Und schon haben wir genau das, was ich in meinem Beitrag beschrieben
hatte: die halbgare Loesung mit nachgeschaltetem Supportaufwand.
Wenn jetzt ein Rotor ins Spiel kommt, kann bereits bei der ZWEITEN
Aufnahme, trotz zweier Tuner, eine Kollision auftreten (wegen der
moeglicherweise unterschiedlichen Satellitenposition der beiden
aufzuzeichnenden Transponder)....

Alles anzeigen

Ich glaube nicht, daß Dream das mit dem Supportaufwand schon abgeschätzt hat - mehr Supportaufwand wegen einer ev. einmal zu häufigen Warnung, oder mehr Supportaufwand wegen Aufnahmen die programmiert, aber nicht abgearbeitet wurden. Denn dann hätte man sicherlich eine 99% Lösung eingebaut anstatt die frustrierten User rätseln zu lassen, warum eigentlich die Aufnahme nicht funktionierte. Seien wir doch ehrlich, wir schimpfen zwar über dumme Meldungen die nicht notwendig wären (Ein Aufnahmetimer will ihre Box abschalten...), aber richtig stören und ärgern tun uns doch Aufnahmen die ohne offensichtlichen Grund nicht funktioniert haben. Supportaufwand (wenn überhaupt) gibt's sicher mehr, wenn Aufnahmen nicht funktionieren als wenn eine Meldung kommt. Außerdem könnte man ja für die paar Rotoruser die Meldung abschaltbar machen, wenn man's schon nicht 100%ig hinkriegt. Auch ein üblicher Ausweg wenn man nicht alle Eventualitäten abdecken will oder kann - gibt dem User wenigstens die Möglichkeit aus zwei schlechten Lösungen die für ihn bessere zu wählen. Dann hat er wenigstens das Gefühl, daß sich der Hersteller bemüht hat

Ich meine, Dream will keine Kapazität in dieses Problem stecken, weil sie einfach meinen, es rechnet sich nicht. Ein paar weniger zufriedenen User sind Dream allemal lieber als noch mehr Verzögerung bei der 8000er.

Wenn nicht massiv der Wunsch der User nach einer Kollisionserkennung kommt und sich die User eh mit 'es ist nicht einfach' abspeisen lassen, wird das auch bei der 800(0) nicht kommen. Aber Sinn eines solchen Forums für eine Firma ist ja auch, die Userwünsche besser einschätzen und ev. darauf eingehen zu können. Wenn die User bezüglich Bedienung und Features eh schon durch den ganzen 'Geiz ist Geil' Müll eine derart niedrige Erwartungshaltung gegenüber Consumer Geräten haben, dann lohnt es sich ja wirklich nicht, da noch mehr Gehirnschmalz reinzustecken. Aber -

Zitat

Gibt's denn überhaupt irgendeinen Receiver am Markt der eine GUI mit einem ResourceManager hat wie ihn enigma2 bietet?
Man muss hier echt einfach ganz objektiv und klar sagen, dass es diesbezüglich doch aktuell schlicht und einfach keinerlei auch nur annähernd gleich gute Alternativen gibt...

- ketzerische Frage - wollt ihr wirklich warten bis euch die Koreaner oder die Chinesen vormachen wie man sowas richtig macht? Wie lange glaubt ihr wird's dann überhaupt noch eine Entwicklungsabteilung in Europa geben, wenn das eh die Chinesen auch können?

Bitte mich nicht falsch verstehen, ich will hier positive Kritik üben und ev. wenn ich mir mal eine 8000 zulege dann einige Schwachstellen beseitigt haben.

Hätte auch sehr großes Interesse an einer Enigma2 Timer-Kollisionswarnung.
Wahrscheinlich kann ein externer Entwickler das schneller bauen als DMM.
Frag doch mal die Jungs von IhaD.

Grüsse

Anfang der 90er habe ich recht intensiv in C programmiert und habe daher ein wenig Ahnung bez. Plausibilitätsprüfungen. Der Rotorbetrieb stellt überhaupt kein Problem dar, denn zeitgleich kann es keine unterschiedlichen Rotorpositionen geben. Überschneidung auf mehr als 2 Transpondern = Error.

Enima2 ist ein sehr komplexes System und ich kann die Programmierer nur bewundern. Und da soll so eine simple Timerprüfung ein Problem darstellen? Würde Dream eine(n) fähige(n) ProgrammierIn damit betrauen, wäre die Sache in 1 - 2 Arbeitstagen erledigt.