Na ja, wenn der Pi als Mediacenter eingesetzt werden soll dann ist die Frage ob er es decodieren kann oder nicht eigentlich ziemlich wichtig finde ich.
Ansonsten kannst du höchstens das Signal durchleiten an ein anderes Gerät.
Das ist nicht nur ziemlich wichtig sondern geradezu entscheidend, wenn man den DVB-Stream nicht nur aufzeichnen (und wo anders ansehen) will.
H.265 kannst auf dem RasPi in Software sicher nicht in Echtzeit decodieren und mich würde sehr wundern, wenn es die Hardwareerweiterung in Hardware macht, weil das seit zig Jahren bei TV-Empfangskarten nicht mehr üblich ist.
@Prolinux: Ihr solltet euch mal was einfallen lassen um Doppelpostings zu vermeiden. Eine laufende ID beim HTML Form-Tag mit auszuliefern und Doppelpostings abzulehnen dessen ID in der Datenbank bereits existiert würde schon ausreichen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 19. Okt 2018 um 02:47.
Von linux-nutzer am Fr, 19. Oktober 2018 um 09:37 #
@1ras: Die Doppelpostings kommen hier eigentlich eher zustande, weil die Website beim Kommentar abschicken gelegentlich etwas langsam ist und durchaus mal ein paar Sekunden mehr braucht. Wenn man dann aus Ungeduld noch ein zweites Mal auf Senden klickt, statt einfach zu warten, kommt ein Doppelposting raus.
Ich weiß, aber schau dir mal die Zeitstempel an, da liegen 2 Minuten dazwischen. Wie lange soll ich denn noch warten, um das zweite mal auf Senden zu klicken?
Eine zufällige ID pro ausgeliefertem HTML-Form-Tag mitsenden und beim Submit vor dem Hinzufügen in der Datenbank nachsehen, ob es diese ID bereit gibt und schon kann dies vermieden werden. (Zufällige ID dürfte besser sein als laufende ID, da man sich die ID dann im Vorfeld nicht merken muss.)
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 19. Okt 2018 um 10:06.
Ich weiß nicht, ob das hilft. Der Engpass ist die Datenbank und so eine ähnliche Maßnahme ist bereits implementiert. Allerdings sollten die Verzögerungen seit dem letzten NB3-Update schon stark reduziert sein.
Wenn du jeden vom Webserver ausgelieferten HTML Form Tag mit einer eindeutigen ID versiehst (z.B. Timestamp in ms + zufällig generierte Zeichenkette sollte eindeutig genug sein) und diesen zusammen mit dem Posting in der Datenbank abspeicherst, dann siehst du auch, wenn ein Submit doppelt kommt und kannst dies entsprechend abfangen.
(Edit) Ich präzisiere es nochmal: Da die ID eindeutig genug ist reicht es aus, sie erst bei einem Submit zusammen mit dem Posting abzuspeichern, so dass nur dann ein Schreibvorgang in die Datenbank nötig ist, wenn er sowieso anstünde.
Der Aufwand ist das Generieren einer eindeutigen ID durch den Webserver (PHP oder was auch immer) und beim Submit ein zusätzlicher lesender Datenbankzugriff um zu sehen, ob die ID bereits existiert. Beides sollte nicht das Problem sein.
Zwischen dem erstem Beitrag und Doppelpost liegen laut Zeitanzeige im Forum 2 Minuten. Die beiden Submits müssen also um über 60 Sekunden zeitverzögert gekommen sein. Das muss aber nicht unbedingt an der Datenbank gelegen haben, WLAN-Verbindungen und 3G/LTE sind nicht immer so stabil wie man es sich wünscht.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 19. Okt 2018 um 12:02.
Na ja, wenn der Pi als Mediacenter eingesetzt werden soll dann ist die Frage ob er es decodieren kann oder nicht eigentlich ziemlich wichtig finde ich.
Ansonsten kannst du höchstens das Signal durchleiten an ein anderes Gerät.
Das ist nicht nur ziemlich wichtig sondern geradezu entscheidend, wenn man den DVB-Stream nicht nur aufzeichnen (und wo anders ansehen) will.
H.265 kannst auf dem RasPi in Software sicher nicht in Echtzeit decodieren und mich würde sehr wundern, wenn es die Hardwareerweiterung in Hardware macht, weil das seit zig Jahren bei TV-Empfangskarten nicht mehr üblich ist.
Dein Einwand ist also mehr als berechtigt.
@Prolinux: Ihr solltet euch mal was einfallen lassen um Doppelpostings zu vermeiden. Eine laufende ID beim HTML Form-Tag mit auszuliefern und Doppelpostings abzulehnen dessen ID in der Datenbank bereits existiert würde schon ausreichen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 19. Okt 2018 um 02:47.@1ras: Die Doppelpostings kommen hier eigentlich eher zustande, weil die Website beim Kommentar abschicken gelegentlich etwas langsam ist und durchaus mal ein paar Sekunden mehr braucht. Wenn man dann aus Ungeduld noch ein zweites Mal auf Senden klickt, statt einfach zu warten, kommt ein Doppelposting raus.
Ich weiß, aber schau dir mal die Zeitstempel an, da liegen 2 Minuten dazwischen. Wie lange soll ich denn noch warten, um das zweite mal auf Senden zu klicken?
Eine zufällige ID pro ausgeliefertem HTML-Form-Tag mitsenden und beim Submit vor dem Hinzufügen in der Datenbank nachsehen, ob es diese ID bereit gibt und schon kann dies vermieden werden. (Zufällige ID dürfte besser sein als laufende ID, da man sich die ID dann im Vorfeld nicht merken muss.)
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 19. Okt 2018 um 10:06.Ich weiß nicht, ob das hilft. Der Engpass ist die Datenbank und so eine ähnliche Maßnahme ist bereits implementiert. Allerdings sollten die Verzögerungen seit dem letzten NB3-Update schon stark reduziert sein.
Wenn du jeden vom Webserver ausgelieferten HTML Form Tag mit einer eindeutigen ID versiehst (z.B. Timestamp in ms + zufällig generierte Zeichenkette sollte eindeutig genug sein) und diesen zusammen mit dem Posting in der Datenbank abspeicherst, dann siehst du auch, wenn ein Submit doppelt kommt und kannst dies entsprechend abfangen.
(Edit) Ich präzisiere es nochmal: Da die ID eindeutig genug ist reicht es aus, sie erst bei einem Submit zusammen mit dem Posting abzuspeichern, so dass nur dann ein Schreibvorgang in die Datenbank nötig ist, wenn er sowieso anstünde.
Der Aufwand ist das Generieren einer eindeutigen ID durch den Webserver (PHP oder was auch immer) und beim Submit ein zusätzlicher lesender Datenbankzugriff um zu sehen, ob die ID bereits existiert. Beides sollte nicht das Problem sein.
Zwischen dem erstem Beitrag und Doppelpost liegen laut Zeitanzeige im Forum 2 Minuten. Die beiden Submits müssen also um über 60 Sekunden zeitverzögert gekommen sein. Das muss aber nicht unbedingt an der Datenbank gelegen haben, WLAN-Verbindungen und 3G/LTE sind nicht immer so stabil wie man es sich wünscht.
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 19. Okt 2018 um 12:02.