Keine Rückmeldung von MV beim Anlegen neuer Abos

[MenchenSued]

Wenn ich ein “einfaches” Abo wie “Sender=ZDF” anlege, dann friert MV 13.7.1 für sehr lange Zeit ein und lässt sich nicht bedienen. Es gibt auch keine Rückmeldung, dass MV gerade beschäftigt ist. Die CPU ist dabei lediglich zu 1% beschäftigt. Falls eine Aktion lange dauert, dann wäre eine Meldung, ein Aktivitätssymbol in Form eines roten Punktes oder ein Laufbalken nicht verkehrt. Auch wäre es gut, wenn man die Aktion abbrechen könnte.
Ursache ist die Abfrage der Dateigröße, denn im Logfile sehe ich zigtausend Zeilen mit “Requesting file size for …<URL>”. Hoffentlich werten die Sender das nicht als DoS.

[DerReisende77]

@menchensued Ja das Verhalten ist normal und entspricht auch den alten Versionen. Ich habe zur Nachvollziehbarkeit nur das log output diesmal sichtbar gemacht. Wenn ein angelegtes Abo zigtausend Treffer erzielt werden die sofort in der Downloadliste angelegt und die fehlenden Daten gesucht. Das ist von Xaver damals gewünschtes Verhalten.
Besser wäre es wenn der Abo verwalten Dialog erst einmal nur intern die Treffer anzeigt und diese erst nach dem Schließen anwendet. So kann der User gemachte Fehler noch korrigieren bevor das Programm während der Suche nicht reagiert. Dafür muss jedoch eine Menge an Code umgeschrieben werden. Es steht aber auf meiner Todo-Liste, genauso wie eine Überholung des Download-Mechanismus.

[MenchenSued]

Danke. Es stellt sich aber doch die Frage, ob die Abfrage jedes einzelnen Treffers sinnvoll ist oder ob die Daten, die in der Filmliste bereits enthalten sind, ausreichen um die Downloadsliste zu füllen. Ein Client sollte hier nicht unnötig zum Crawler werden.

[gerdd]

@menchensued @DerReisende77

Hmmmmm …

Das habe ich mich manchmal schon gefragt:

Da laufen einige Crawler, die teilweise wohl viel Verkehr auf den Servern “anrichten” - mit einem Anspruch, eine gewisse Vollstaendigkeit der Filmlisten zu erreichen.

Jetzt mal theoretisch gedacht - wenn dabei ein gewisser Teil Informationen gesammelt wird, den dann hinterher niemand nutzt … Ich kann das nicht abschaetzen, aber es koennte ja sein, dass etliches von dm Aufwand vergeblich ist. Moeglicherweise koennte man effizienter mit den Ressourcen umgehen, wenn man die Crawler weniger detaillierte Daten sammeln laesst und dann den Client die restliche Arbeit machen laesst, wenn sich doch einmal jemand fuer den Beitrag interessiert.

Das ist jetzt nur mal eine theoretische Ueberlegung auf ganz hoher Ebene und keineswegs ein abgeschlossener Gedanke, der zur Umstrukturierung der Software fuehren soll!!!

In letzter Konsequenz koennte ich mir sogar ein Design vorstellen, das die von Clients er-crawl-ten Ergebnisse in einer zentralen Datenbank sammelt, von wo sie dem naechsten Client gleich uebergeben werden koennten - eine Art Cache, wenn man so will.

Aktuell weiss ich viel zu wenig darueber, wie die Arbeit zwischen Crawlern und Clients aufgeteilt ist, als dass ich hier mehr als eine ganz oberflaechliche Idee (diese) beisteuern kann.

[DerReisende77]

@menchensued sagte in Keine Rückmeldung von MV beim Anlegen neuer Abos:

Danke. Es stellt sich aber doch die Frage, ob die Abfrage jedes einzelnen Treffers sinnvoll ist oder ob die Daten, die in der Filmliste bereits enthalten sind, ausreichen um die Downloadsliste zu füllen. Ein Client sollte hier nicht unnötig zum Crawler werden.

Nein die Frage stellt sich nicht, da das Programm genau dies nicht tut.
Als Xaver die Abofunktion hinzugefügt hat ging er davon aus das der Nutzer des Programms in der Regel sich der Konsequenzen seines Handelns bewusst war. Sprich: Wer ein Abo nur mit Sender ZDF anlegte sollte gewusst haben das dies eine Menge Treffer auslöst (Stand gerade habe ich ca. 50k ZDF Einträge) und so das Programm sehr lange einfriert. Also wurde die Anzahl der bereitgestellten Informationen reduziert. Das führte dazu das die Nutzer meckerten es fehl die Angabe der Dateigröße, Filmlänge,etc… es wurde also für die Standardauflösung genau die Information nun in die Liste hineingepackt, während die “exotischen” Einträge aus Effizienzgründen diese nicht in der Filmliste besitzen ( Xaver hat die Server damals selbst bezahlt).
So gesehen ist das einfach: Legt der Nutzer ein Abo über 50k ZDF Einträge in Standardauflösung an, wartet er seine Sekunden, es werden aber in der Regel keine oder nur wenige Netzabfragen gestartet.
Schnitt 2021: Jeder will HQ laden: Hier fehlen die Informationen. Also (da die Nutzer dies wollen) müssen die Informationen rangeholt werden und das Programm tut dies geflissentlich. Es macht genau das was gefordert war/ist.

Aber die Filmliste wird nicht um diese Informationen erweitert werden da dann der Ballast noch größer für uns wird und der jetzt schon utopisch hohe Durchsatz dann noch mehr explodiert. Da nehme ich lieber in Kauf dass der Nutzer seine Leitung opfert.

[DerReisende77]

@gerdd sagte in Keine Rückmeldung von MV beim Anlegen neuer Abos:

@menchensued @DerReisende77

Hmmmmm …

Das habe ich mich manchmal schon gefragt:

Da laufen einige Crawler, die teilweise wohl viel Verkehr auf den Servern “anrichten” - mit einem Anspruch, eine gewisse Vollstaendigkeit der Filmlisten zu erreichen.

Jetzt mal theoretisch gedacht - wenn dabei ein gewisser Teil Informationen gesammelt wird, den dann hinterher niemand nutzt … Ich kann das nicht abschaetzen, aber es koennte ja sein, dass etliches von dm Aufwand vergeblich ist. Moeglicherweise koennte man effizienter mit den Ressourcen umgehen, wenn man die Crawler weniger detaillierte Daten sammeln laesst und dann den Client die restliche Arbeit machen laesst, wenn sich doch einmal jemand fuer den Beitrag interessiert.

Guter Ansatz, aber leider falsch gedacht. Folgendes Beispiel: Der crawler sucht bei Sender X einmalig die Informationen und packt sie in die Filmliste. Dann hast Du einmal Traffic um die Infos zu bekommen, jeder Client lädt von uns die Daten per Filmliste.
Macht er das nicht und ich überlasse den Clients die Arbeit ergibt sich folgendes Bild: Nehmen wir an wir haben 5000 Nutzer (was realistisch ist) und jeder will nur von Sender X laden. Momentan kann er sich die meisten Informationen aus der Filmliste holen und es läuft worst case nur ein Download des Films über die Leitung. Ohne die Informationen in der Liste fragen 5000 Clients genau diesselbe Information von Sender X jedesmal ab -> 5000 Abfragen vs 1 crawler, und zwar jedes Mal wenn das Programm neu gestartet wurde und man auf den Eintrag klicken würde.
Genau deshalb wurde die Filmliste immer wieder Stück für Stück um Informationen ergänzt. Und weil Leute (heutzutage schwer nachvollziehbar) die Sachen auch offline sehen wollen.

Das ist jetzt nur mal eine theoretische Ueberlegung auf ganz hoher Ebene und keineswegs ein abgeschlossener Gedanke, der zur Umstrukturierung der Software fuehren soll!!!

In letzter Konsequenz koennte ich mir sogar ein Design vorstellen, das die von Clients er-crawl-ten Ergebnisse in einer zentralen Datenbank sammelt, von wo sie dem naechsten Client gleich uebergeben werden koennten - eine Art Cache, wenn man so will.

Das ist ein guter Ansatz über den wir auch schon häufig diskutiert haben und es auch schon Prototypen hierzu gab. Folgende Probleme ergeben sich hierbei:

• Wie wird die Offline-Fähigkeit aufrecht erhalten? Die MediathekView-App soll offline nutzbar sein. Das war der Grund der Entwicklung.
• Wird der Nutzer gezwungen, die Mitarbeit durch Nutzung der Software zuzulassen? Oder kann er sich aus verschiedenen Aufgaben ausklinken? Welche Auswirkungen hat das dann ggf. für ihn?
• Wie stelle ich sicher dass der Nutzer bevor er zustimmt DSGVO konform über die dadurch erhobenen Daten aufgeklärt wird? Er muss ja in Teilen nachverfolgbar werden für den Server wenn Aufträge versendet und Antworten zurück kommen. Zum Beispiel macht es ja keinen Sinn Aufträge für österreichische oder schweizer Einträge an deutsche Clients zu senden da die in der Regel am Geofence scheitern und nur “verboten” dann zurück liefern.
• Auch nicht zu vergessen: Wie vehindere ich zuverlässig das irgendwelche Clowns den Quellcode laden, ihn etwas modifizieren und Blödsinn an den Server zurück liefern? Der Quelltext ist nicht closed-source und die gelieferten Informationen können nicht 100% auf Zuverlässigkeit geprüft werden.

[Georg-J]

@derreisende77 sagte in Keine Rückmeldung von MV beim Anlegen neuer Abos:

[…] es wurde also für die Standardauflösung genau die Information nun in die Liste hineingepackt, während die “exotischen” Einträge aus Effizienzgründen diese nicht in der Filmliste besitzen ( Xaver hat die Server damals selbst bezahlt).
So gesehen ist das einfach: Legt der Nutzer ein Abo über 50k ZDF Einträge in Standardauflösung an, wartet er seine Sekunden, es werden aber in der Regel keine oder nur wenige Netzabfragen gestartet.
Schnitt 2021: Jeder will HQ laden: Hier fehlen die Informationen. Also (da die Nutzer dies wollen) müssen die Informationen rangeholt werden und das Programm tut dies geflissentlich. Es macht genau das was gefordert war/ist.

Aber die Filmliste wird nicht um diese Informationen erweitert werden da dann der Ballast noch größer für uns wird und der jetzt schon utopisch hohe Durchsatz dann noch mehr explodiert. Da nehme ich lieber in Kauf dass der Nutzer seine Leitung opfert.

Wenn jeder HD laden will (ja auch ich will das), könnte man bei der geplanten Umstellung der Filmliste statt der Standardauflösung dann die HQ-Auflösung für die Basis-Angaben (URL, Dateigröße) verwenden.

Was Traffic-Verminderung bei den ÖR-Servern betrifft, könnte ich mir vorstellen, dass fehlende Daten in der Filmliste über die MV-Server abgefragt werden. Diese könnten die Daten beim ersten Mal vom ÖR-Server holen und für später cachen.

[gerdd]

@derreisende77 sagte in Keine Rückmeldung von MV beim Anlegen neuer Abos:

Guter Ansatz, aber leider falsch gedacht. Folgendes Beispiel: Der crawler sucht bei Sender X einmalig die Informationen und packt sie in die Filmliste. Dann hast Du einmal Traffic um die Infos zu bekommen, jeder Client lädt von uns die Daten per Filmliste.

Gegenbeispiel: Der Crawler durchsucht 10000 Seiten, findet 3000 Sendungen, aber nur 300 davon werden überhaupt nachgefragt … auch so generiert man Overhead.

Deshalb hatte ich angedeutet, dass man, um so etwas zu optimieren, eigentlich vieles über die Nachfrage nach den Sendungen wissen müsste.

In letzter Konsequenz koennte ich mir sogar ein Design vorstellen, das die von Clients er-crawl-ten Ergebnisse in einer zentralen Datenbank sammelt, von wo sie dem naechsten Client gleich uebergeben werden koennten - eine Art Cache, wenn man so will.

Das ist ein guter Ansatz über den wir auch schon häufig diskutiert haben und es auch schon Prototypen hierzu gab. Folgende Probleme ergeben sich hierbei:

• Wie wird die Offline-Fähigkeit aufrecht erhalten? Die MediathekView-App soll offline nutzbar sein. Das war der Grund der Entwicklung.

Offline? Zumindest der Download der Video-Dateien muss ja wohl online erfolgen?

• Wird der Nutzer gezwungen, die Mitarbeit durch Nutzung der Software zuzulassen? Oder kann er sich aus verschiedenen Aufgaben ausklinken? Welche Auswirkungen hat das dann ggf. für ihn?

Ich hatte eigentlich nicht an Zwang gedacht - die Rückführung der ermittelten Daten war eigentlich sowieso nur eine Zusatzidee. Die Daten könnten total anonym eingereicht werden und würden ja sowieso nur die Inhalte der Mediatheken reflektieren, die man nur deshalb nicht von dort holt, um die Bandwidth von deren Servern zu schonen.

• Wie stelle ich sicher dass der Nutzer bevor er zustimmt DSGVO konform über die dadurch erhobenen Daten aufgeklärt wird? Er muss ja in Teilen nachverfolgbar werden für den Server wenn Aufträge versendet und Antworten zurück kommen. Zum Beispiel macht es ja keinen Sinn Aufträge für österreichische oder schweizer Einträge an deutsche Clients zu senden da die in der Regel am Geofence scheitern und nur “verboten” dann zurück liefern.

Ein paar exzellente Gründe, kein Modell mit “Auftragsvergabe” zu entwickeln.

• Auch nicht zu vergessen: Wie vehindere ich zuverlässig das irgendwelche Clowns den Quellcode laden, ihn etwas modifizieren und Blödsinn an den Server zurück liefern? Der Quelltext ist nicht closed-source und die gelieferten Informationen können nicht 100% auf Zuverlässigkeit geprüft werden.

Das ist allerdings ein interessantes Problem … (wobei “closed source” ja bekanntlich der schwächste Schutz ist, den man sich vorstellen kann.) Im Extremfall würde das das Cachen der vom Anwender ermittelten Daten hinfällig machen - mehr nicht. Wäre schade.

Alles in allem, das war jetzt so noch nicht als fertiges Konzept gedacht, aber so ganz abwegig scheint es ja nicht zu sein, wenn darüber schon vorher nachgedacht wurde … Meine Idee war lediglich, Möglichkeiten zu suchen, wie man mit möglichst geringer Belastung der Sender-Server einen möglichst guten Überblick über deren Angebote gewinnen kann - und da seid ihr schon ziemlich weit gekommen, aber hier und da klingt es doch durch, dass die Belastung manchmal doch ein Stück höher ist als man sich wünschen würde.

(Über Modelle, bei denen die Clients - z.B. aus Sicherheitsgründen - per API Code auf den MV-Servern aufrufen, will ich jetzt mal noch gar nicht nachdenken, denn da sehen wir uns vermutlich auch deutlichen Grenzen des Möglichen gegenüber.)