Sundtek Support Forum

Sobald das Geraet angeschlossen wird, werden die Lirc Konfigurationen aktualisiert um die FB des USB Sticks zu unterstuetzen.
Bis wir dies im Installer konfigurierbar gemacht haben koennen Sie dies durch loeschen der Autostart-Konfiguration manuell abschalten:

sudo rm /etc/udev/rules.d/80-remote-eeti.rules* /lib/udev/rules.d/80-remote-eeti.rules*


Version: http://www.sundtek.de/support/empia_installer_100222.sh
sha1sum: ff20a40e2d507d73d866b950ea490f01b8c29b28

* Standby Funktionalitaet des USB Sticks wurde freigeschalten, das Geraet kuehlt nach 15 Sekunden Inaktivitaet ab (dies erhoeht ebenfalls die Lebensdauer)
* neue DVB-C/DVB-T only Geraeteserie wurde hinzugefuegt
* Bugfix VLC 1.0.2
* Notebook Standby Support wurde aktualisiert.
* Videostandards (PAL-M wurde nachgebessert, die Qualitaet von SECAM-L wird in einem Hotfix noch nachgebessert)
* Audio threshold Option hinzugefuegt zum manuellen nachbessern der Audio Verzoegerung fuer analog TV (z.b fuer VLC)
* mediaclient unterstuetzt jetzt ebenfalls den QAM128 (Q128) Parameter (DVB Applikationen sollten damit jedoch keine Probleme gehabt haben, da mediaclient unabhaengig funktioniert - es gab soweit keine Treiberaenderung bezueglich QAM128)
* Bugfix bezüglich Betrieb mit mehreren Geräten (20. Feb 2010)
* Trident Firmware wurde aktualisiert, SECAM-L/Frankreich funktioniert ab jetzt (22. Feb 2010)

Fuer analog TV und DVB-T kann Windows Mediacenter verwendet werden. Fuer DVB-C wurde derzeit lediglich DVBViewer und TotalMedia getestet, eventuell kann ProgDVB noch funktionieren (der Status ist uns hierbei derzeit jedoch unbekannt, ein eigener Windows Player wird in den naechsten Monaten hinzukommen), vorerst arbeitet unser Applikationsentwicklerteam an einem angepassten Mediacenter fuer Linux und Mac.

Das Problem wurde intern bereits geloest und wird mit dem naechsten Update verfuegbar sein.

Another small update, our engineering team is doing some more tests with the driver on MacOSX (10.5+) now:
* DVB-C working okay
* DVB-T working okay
* AnalogTV (including audio) working okay
* FM radio working okay
* Remote control working okay

For ATSC (digital TV standard which is used in Canada and US)
* ATSC working okay

Application:
* Analog TV (including audio) working okay
* DVB-C in progress
* DVB-T in progress
* FM Radio in progress
* Remote control


For ATSC (digital TV standard which is used in Canada and US)
* ATSC working okay

further updates are expected to come up quickly.

Edit 05 Feb, added Remote, was of course working too already with the driver

norm= is a confusion with the old video4linux (v4l1) protocol, with the new protocol you have to use normid=[number infront of the actual norm]
You are mixing up the v4l1 with the v4l2 syntax

See following line in your mplayer parameter:
tv.c: norm_from_string(pal): Bogus norm parameter, setting default.


Hallo,

vielen Dank für Ihre schnelle Antwort.
Der Treiber ist dazu fähig, einen TV-Stream übers Netzwerk zu leiten. Sind die Latenzen hier nicht mindestens genauso hoch?

Nein, Qemu versucht zusaetzlich nocheinmal einen Host zu emulieren. Die Paketverarbeitung ist bereits eine kritische Angelegenheit. Sofern das ganze ueber das Netzwerk verwendet wird werden extra Puffer verwendet welche den Bedarf an Geschwindigkeit des Auslesevorganges entschaerfen.
QEMU arbeitet jedoch nicht mit solchen Puffern.
Das einzige was Sie versuchen koennen ist die Netzwerkfunktionalitaet zu verwenden, hierbei sind in Zukunft auch noch einige Updates geplant (z.B um die Radiofunktionalitaet und eventuell analog TV streaming ueber das Netzwerk zu unterstuetzen).

Solange die Pakete durchgereicht werden und das System abwartet bis sie auf der anderen Seite ausgelesen werden ist die Latenz diesbezueglich zu hoch. Abhilfe kann hierbei lediglich durch eine Verbesserung bei QEMU durchgefuehrt werden.

Der Unterschied ist natürlich, dass die Kommunikation zwischen Haupttreiber (der dem Netzwerk den Stream zur Verfügung stellt) und dem USB-Stick sehr geringe Latenzen hat und es eine Latenz dann nur zwischen den verschiedenen Treiberinstanzen gibt. Aber das bedeutet ja, dass das Ergebnis "LiveTV" an sich nicht von Latenzen abhängt, sondern nur das Kommunikationsprotokoll zwischen Treiber und Stick. Kann man in dem Fall durch ein Firmwareupdate oder ähnliches dieses Kommunikationsprotokoll ändern und die Latenzanfälligkeit verringern?

Im Normalfall würde ich einem Hersteller so einen Änderungsvorschlag nicht machen und erst recht nicht an eine Umsetzung glauben, aber durch Ihre regelmäßigen Treiberupdates und Ihre Kommunikation hier im Forum bin ich in gewisser Weise ermutigt. Hier nebenbei ein großes Lob an Ihren Support! Ich kenne eigentlich keine Firma, die sich so darum kümmert, durch Treiberupdates regelmäßig neue Funktionen in eine bereits verkaufte Hardware einzubauen.

Wir sind bemueht eine gute Qualitaet des Treibers bestmoeglichst zu garantieren. Unsere Entwickler arbeiten ebenfalls auf Hochtouren an kommenden Applikation.

Wird naechste Woche ueberprueft werden.