Ich möchte hier kurz auf zwei der Kompromisse eingehen, die im Zusammenhang mit der Umstellung auf die Web Anwendung von VCR.NET 3.0 gemacht wurden.
Heute ist es im VCR.NET Recording Manager so, dass die Anzeige der geplanten Aufzeichnungen auf eine feste Anzahl beschränkt ist. Ein Blättern ist nicht möglich. Möchte man mehr sehen, als die Liste hergibt, so kann man zwar diese Anzahl erhöhen, wird aber bei der Abfrage eine erhebliche Mehrbelastung des Windows Dienstes feststellen. Die Ursache ist, dass recht pingelig ermittelt wird, welche Aufzeichnungen stattfinden. Bei überlappenden Aufzeichnungen muss immer die vorherige Aufzeichnung bekannt sein, damit der genaue Startpunkt und die damit resultierenden Konsequenzen für Mehrkanalaufzeichnungen korrekt berücksichtigt werden. Zu kompliziert? Ok, hier das Beispiel der Web Anwendung: diese erlaubt die Anzeige für ein festes Zeitintervall, sagen wir mal 7 Tage (das ist die Voreinstellung, die man verändern kann). Die erste Seite der Liste ist im Sinne des alten Recording Managers exakt. Man kann aber nun auch in die Zukunft schauen und sich den Plan der nächsten Woche anschauen. Dabei beginnt die Liste immer um 00:00 Mitternacht. Findet zu diesem Zeitpunkt keine Aufzeichnung statt, so ist die Anzeige exakt. Findet aber eine Aufzeichnung statt, die etwas früher beginnt – sagen wir mal um 23:00 – so wird diese als problematisch (beginnt zu spät) markiert. Eigentlich müßte in einem solchen Fall der Testzeitpunkt mindestens bis zum Beginn der Aufzeichnung zurück verschoben werden und die Auswertung erneut gemacht werden. Was aber, wenn zu diesem Zeitpunkt eine frühere Aufzeichnung noch läuft? Man sieht, dass ist etwas lästig in der Auswertung. Selbst wenn es technisch nicht oft vorkommen wird, der Algorithmus müßte alle Situationen abdecken. Der Kompromiß an dieser Stelle ist trivial: entsteht eine solche Situation, so schaut man sich einfach den Aufzeichnungsplan der Woche davor an – der letzte Eintrag gibt in allen praktisch relevanten Situationen die korrekten Aufzeichnungsdaten wieder [nicht praktisch relevant ist hier nur, dass über den gesamten Betrachtungszeitraum ununterbrochen Aufzeichnungen durchgeführt werden].
Ein ähnliches Problem ergibt sich bei der Programmzeitschrift (vormals EPG genannt). Hier kann in der Liste nun auch (vorwärts) geblättert werden. Dabei wird der Zeitpunkt des letzten Eintrags auf einer Anzeigeseite als Anfangspunkt für die nächste Seite genommen. Dabei erscheint genau dieser Eintrag erst einmal doppelt – das ist meiner Ansicht nach kein Problem. Es kann aber nun vorkommen, dass die erlaube Anzahl von Einträgen in der Liste (die vom Anwender festgelegt werden kann) nicht ausreicht, um alle Sendungen zu zeigen, die zu diesem Zeitpunkt beginnen (eine Begrenzung auf 20 Einträge bei einer Anzeige von 20:15 ist dabei so ein Fall). In dieser Situation würde der einfache Algorithmus immer wieder zur gleichen Seite blättern! Der Kompromiß hier ist genauso trivial wie oben: die erlaubte Anzahl wird in dieser Situation ignoriert und es werden so viele Sendungen aufgelistet, dass die letzte in der Liste einen anderen Startzeitpunkt als die erste hat.
Im Moment denke ich, dass diese Kompromisse kein Problem in der Bedienbarkeit der Web Anwendung darstellen.
Jochen
