Sundtek Support Forum
Deutsch => Sundtek MediaTV Pro => Treiber => Thema gestartet von: Sundtek am Mai 04, 2010, 04:07:25 Nachmittag
-
Version: http://www.sundtek.de/media/sundtek_installer_100506.sh
md5sum: acaf575a7a5d6d2abaa8ac29b304f31d
* MIPSel Architektursupport hinzugefuegt
* Interne Ueberpruefung ob ein Geraet bereits registriert wurde (Korrektur da einige wenige Kernelversionen USB Geraete doppelt benachrichtigen).
* Der Installer funktioniert nun ebenfalls mit BusyBox (ash), ein manuelles Setup entfaellt nun auf embedded Systemen
* Der Treiber wird nun bei Ubuntu bevor der PC in den Standby Modus geht gestoppt, und nach dem Aufwachen wieder gestartet
* Linux VDR wird ab dieser Version mit mehreren Geraeten zu 100% unterstuetzt - vielen Dank an alle die uns geholfen haben die letzten Probleme zu finden.
-
Seit einiger Zeit ist es mir nicht mehr möglich /opt/bin/mediasrv mit Apparmor zuschützen. Was ich bei einer Audit feststelle ist jedefalls, dass ein Zugriff auf verschiedene Network Servces erfolgt. Und das hab ich aber überhaupt nicht konfiguriert!
1 - #include <abstractions/apache2-common>
2 - #include <abstractions/nameservice>
3 - network inet stream
/opt/bin/mediasrv --build
Build date: May 6 2010
-
Apparmor sollte eher fuer Server gedacht sein.
Der Treiber baut keine Verbindungen zum Internet auf, die Clients kommunizieren jedoch intern ueber Domain Socket Verbindungen (welche man Netzwerkverbindungen in etwa gleichsetzen kann). Sollten Sie eine Applikation nicht auf den Treiber zugreifen lassen wollen sperren Sie einfach den Zugriff auf /etc/ld.so.preload fuer die jeweilige Applikation.
1-3 hat nichts mit dem ganzen zu tun.
-
Ich habe die Datei /etc/ld.so.preload vor einiger Zeit schon gelöscht. Also kann es daran nicht liegen.
-
mediasrv koennte unter umstaenden mittels Pulseaudio noch externe Verbindungen zu einem Soundserver herstellen (dies kommt aber sehr auf die lokale Pulseaudio Konfiguration an).
-
Nach dem Update auf Ubuntu 10.04 habe ich unter kaffeine die gleichen Probleme, wie es sie schon vor längerer Zeit mal gab. Nach dem Starten von kaffeine kommt die Meldung von Sorry - Kaffeine: "No available device found". Nach Deinstallation, Neuinstallation und /opt/bin/mediaclient -c bzw. .... -D DVBC für DVB-C funktioniert kaffeine wieder. Komisch ist nur, dass unter Ubuntu 10.04 das Device1 gefunden werden muss, denn sonst würde tvtime ebenfalls nicht ohne diese "Neustallation" laufen, aber tvtime läuft auch so.
Kann ich etwas tun oder müssen Sie am Treiber etwas ändern?
-
Was zeigt folgender Befehl denn an:
/opt/bin/mediaclient --lc
Dies sollte ausgeben welche Programme mit dem Treiber verbunden sind.
Kann unter Umstaenden vorkommen das ein bereits installiertes Programm die analoge Schnittstelle belegt und dadurch nur analog TV funktioniert (z.B audio device)
Durch einen Treiberneustart werden alle Verbindungen welche zum Treiber hergestellt wurden beendet.
-
Kläre ich, sobald ich wieder an "dem" Rechner bin.
Als Vorweginfo:
Es wurden weder Hardware noch irgendwelche Programmpakete installiert. Mit Ubuntu 9.10 64-bit lief mit dem Treiber 100220 sowohl tvtime, als auch kaffeine einwandfrei. Heute habe ich auf Ubuntu 10.04 upgedatet (keine Neuinstallation). Ausprobiert hatte ich den Treiber 100220 (weil dieser ja bisher einwandfrei lief) und den aktuellen 100506. Aufgefallen ist mir noch, dass ich unter Ubuntu 10.04 neben der Treiberneuinstallation unter kaffeine unter Einstellungen in einem Fall auch noch den Kabelanbieter BW für DVB-C neu einstellen musste, weil das entsprechende Feld leer war.
-
Hallo zusammen,
sind irgendwelche Probleme mit Ubuntu Lucid Lynx bekannt ? Kann auf Ubuntu 10.04 leider keinen w_scan mehr durchführen lassen. Es werden keine Sender gefunden. Unter älterem Ubuntu kein problem.
Im Medialog steht :
QAM Auto modulation not supported by device the driver indicates this option in the capability
Viele Dank für die Hilfe
Grüße
Peter
-
Wie scannen Sie denn? w_scan ist leicht etwas unterschiedlich zwischen den alten/neuen Ubuntu Versionen, verwenden Sie lediglich die mit Ubuntu mitgelieferte w_scan Version.
Unter Ubuntu Lucid (10.04):
$ w_scan -f c -c DE
w_scan version 20091230 (compiled for DVB API 5.1)
using settings for GERMANY
DVB cable
DVB-C
frontend_type DVB-C, channellist 7
output format vdr-1.6
Info: using DVB adapter auto detection.
/dev/dvb/adapter0/frontend0 -> DVB-C "Sundtek DVB-C": good :-)
Using DVB-C frontend (adapter /dev/dvb/adapter0/frontend0)
-_-_-_-_ Getting frontend capabilities-_-_-_-_
Using DVB API 5.1
frontend Sundtek DVB-C supports
INVERSION_AUTO
QAM_AUTO not supported, trying QAM_64 QAM_256.
FEC_AUTO
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
searching QAM64...
73000: sr6900 (time: 00:00) sr6875 (time: 00:04)
81000: sr6900 (time: 00:07) sr6875 (time: 00:11)
113000: sr6900 (time: 00:15) (time: 00:19) signal ok:
QAM_64 f = 113000 kHz S6900C999
-
Ja, genau so, nur das ich leider keine Sender finde :-/
Kann man das Device noch irgendwie initialisieren ?
Übrigens habe das letzte "apt-get dist-upgrade" gemacht.
Gibts evtl. kernel probleme ?
Noch als Hinweis:
Benutze das neue "yavdr 2.0" basierend auf Ubuntu 10.04
Grüße
Peter
-
senden Sie bitte /var/log/mediasrv.log an kontakt at sundtek de
QAM Auto modulation not supported by device the driver indicates this option in the capability
das heisst das die Applikation QAM Auto gescannt hat was falsch ist, es kann nur nach QAM64/QAM128/QAM256 gescannt werden (der Treiber 'sagt' dies der Applikation eigentlich auch, wenn die Applikation dies ignoriert liegt ein Fehler vor). Bei unseren Tests ist dieser Fehler nirgendwo ersichtlich. Wir entwickeln derzeit ebenfalls auf Ubuntu 10.04
Edit:
...
dumping lists (368 services)
Kunde hat es soweit hinbekommen, waren wohl die falschen Parameter bei w_scan gesetzt.
-
Was zeigt folgender Befehl denn an:
/opt/bin/mediaclient --lc
Dies sollte ausgeben welche Programme mit dem Treiber verbunden sind.
Kann unter Umstaenden vorkommen das ein bereits installiertes Programm die analoge Schnittstelle belegt und dadurch nur analog TV funktioniert (z.B audio device)
Durch einen Treiberneustart werden alle Verbindungen welche zum Treiber hergestellt wurden beendet.
-
Kläre ich, sobald ich wieder an "dem" Rechner bin.
Als Vorweginfo:
Es wurden weder Hardware noch irgendwelche Programmpakete installiert. Mit Ubuntu 9.10 64-bit lief mit dem Treiber 100220 sowohl tvtime, als auch kaffeine einwandfrei. Heute habe ich auf Ubuntu 10.04 upgedatet (keine Neuinstallation). Ausprobiert hatte ich den Treiber 100220 (weil dieser ja bisher einwandfrei lief) und den aktuellen 100506. Aufgefallen ist mir noch, dass ich unter Ubuntu 10.04 neben der Treiberneuinstallation unter kaffeine unter Einstellungen in einem Fall auch noch den Kabelanbieter BW für DVB-C neu einstellen musste, weil das entsprechende Feld leer war.
-
Diese Ausgabe kommt bei /opt/bin/mediaclient --lc - wenn kaffeine nicht läuft:
erich@T500erich:~$ /opt/bin/mediaclient --lc
**** List of Media Clients ****
/dev/dvb/adapter0/frontend0:
No client connected
/dev/dvb/adapter0/dvr0:
No client connected
/dev/dvb/adapter0/demux0:
No client connected
/dev/video1:
No client connected
/dev/vbi0:
No client connected
/dev/radio0:
No client connected
/dev/rds0:
No client connected
/dev/mediainput0:
No client connected
/dev/dsp2:
No client connected
erich@T500erich:~$
Nach Treiberde- und -neuinstallation und wenn kaffeine läuft kommt folgende Ausgabe:
erich@T500erich:~/Sundtek_MediaTV_Gold$ /opt/bin/mediaclient --lc
**** List of Media Clients ****
/dev/dvb/adapter0/frontend0:
2473 ... kaffeine
/dev/dvb/adapter0/dvr0:
2473 ... kaffeine
/dev/dvb/adapter0/demux0:
2473 ... kaffeine
2473 ... kaffeine
2473 ... kaffeine
2473 ... kaffeine
/dev/video1:
No client connected
/dev/vbi0:
No client connected
/dev/radio0:
No client connected
/dev/rds0:
No client connected
/dev/mediainput0:
No client connected
/dev/dsp3:
No client connected
erich@T500erich:~/Sundtek_MediaTV_Gold$
tvtime läuft davon unabhänig.
-
ok die Ursache fuer dieses Problem ist das der Treiber vor KDE bzw. hald gestartet wird und HAL (Hardware Abstraction Layer) das Geraet im Nachhinein nicht kennt.
Ein Workaround waere das Geraet neu anzuschliessen, wir werden dies mit dem naechsten Update beruecksichtigen.
-
Das ging aber flott. Danke.
Ich warte jetzt einfach mal das nächste Update ab.
-
Diese 'Zwischenversion' sollte das Hardware Abstraction Layer Registrierungs Problem soweit loesen, und damit sollte Kaffeine nach einem Reboot wie gewohnt ohne das Geraet neu anschliessen zu muessen funktionieren:
http://www.sundtek.de/media/sundtek_installer_100620.sh
(es handelt sich hierbei noch um eine Entwicklerversion, die naechste offizielle Release wird in ca. einer Woche freigegeben werden)
-
Apparmor sollte eher fuer Server gedacht sein.
Das hat doch nichts mit einem Server zu tun. Apparmor oder SElinux sind genau richtig für geschlossene Programme wie z.B. auch Skype. Nur bei Mediasrv bekomme ich das seit einigen Versionen nicht mehr zum laufen.
-
App Armor sollte in der Syslog Datei anzeigen welche Rule es blockiert.
Bei unseren Tests mit dem Ubuntu Server Kernel gab es soweit keine Probleme, sollten wir etwas uebersehen haben wuerden wir dies natuerlich gerne beruecksichtigen.
-
In welchen Mode läuft den bei euch Apparmor? Im enforce Mode läuft das bei mir nicht. Zumindest nicht nach einem Neustart. Da hilft dann auch keine Audit weiter. Könnt ihr mir ein Profil zur Verfügung stellen? Das wäre klasse.
-
Bezueglich App Armor, es gibt einen offiziellen Apparmor Support Chat auf irc.oftc.net #apparmor
Als Chat Client eignet sich irssi unter Linux/BSD/..
Wir sind soweit lediglich auf Video spezialisiert, auf etwaige Linux Erweiterungen welche einen eigenstaendigen Support enthalten verweisen wir am Besten weiter.
Unser Treiber wird systemweit in Ihrem Fall maximal als Netzwerkapplikation laufen welche Unix Domain Sockets zur internen Kommunikation verwendet. Dies sollte nicht von Apparmor geblockt werden.
-
OK, ich hab jetzt endlich wieder ein funktionierendes Profil zusammen. Es zeigt sich auch wieder wie bei allen anderen Versionen, dass der Treiber unter bestimmten Umständen Zugriffe auf TCP IPv4 und IPv6 versucht.
/opt/bin/mediasrv {
deny network inet stream,
deny network inet6 stream,
-
Die einzigen Netzwerkverbindungen welche der Treiber erstellt sind:
1. Durch das Netzwerkfeature, der Socket wird erstellt jedoch solange das Feature nicht aktiviert wird - wird der Port nicht reserviert
2. Pulseaudio, zustaendig ist hierfuer jedoch ausschliesslich die Pulseaudio Bibliothek vom System, die Pulseaudio Session wird jedoch direkt in den Treiber geladen.
3. Die interne Kommunikation findet mittels Unix Domainsockets statt
Darueber hinaus gibt es keinerlei Verbindung zu unseren oder anderen Servern. Fehler bzw. Probleme mit AppArmor sollten dem AppArmor Team mitgeteilt werden. (z.B.: mittels IRC irc.oftc.net #apparmor)
-
Dann wird wohl Punkt 1 der Grund dafür sein. Warum soll ich mich da an einen Apparmor Support wenden? Wenn Apparmor hier einen Zugriff feststellt, wird das auch stimmen.
-
Da Apparmor Entwickler am Besten wissen wie man solche Faelle je nach System einpflegen kann. Auch nehmen wir an das AppArmor einige Faelle nicht sonderlich gut behandelt und noch etwas Allgemeines finetuning in den mitgelieferten Rules benoetigen. Wir hatten uns bereits mit einigen Entwicklern unterhalten, fuer Multimediasysteme ist AppArmor nicht besonders nuetzlich. Fuer Serversysteme welche sich nicht besonders haeufig aendern hat es unter Umstaenden seinen Anwendungsfall.
-
Das mag vielleicht die Ansicht von Sundtek sein. Für mich und für viele Andere User ist es aber sehr nützliches Werkzeug. Man kann damit etliche Programme wie z.B. Skype, Teamviewer, Firefox, Mediasrv überwachen und so zum Teil sogar Programmierfehler entdecken. Warum sonst wird allen modernen Desktop- Distributionen Apparmor oder SElinux per default im Kernel aktiviert oder als Modul geladen?
-
Fuer den durchschnittlichen Anwender ist es einfach zu kompliziert. Es kann nicht das Ziel sein jedem Benutzer eine manuelle Textkonfiguration aufzuzwingen um verschiedene Applikationen zum Laufen zu bekommen.
Ubuntu hat zudem standardmaessig ein relativ lockeres Setup.
AppArmor hat durchaus seine Berechtigung, jedoch hauptsaechlich fuer eine etwas erfahrenere Zielgruppe.
-
Unter Fedora 13 klappt die Installation Out of the box nicht:
SELinux hat auf Ihrem System ein verdächtiges Verhalten entdeckt
Zusammenfassung
SELinux verhindert /usr/libexec/hald-probe-video4linux "connectto" Zugriff on @/de/sundtek/mediasocket.
Detaillierte Beschreibung
[hald-probe-vide hat einen zugelassenen Typ (hald_t).Dieser Zugriff wurde nicht verweigert.]
SELinux verweigerte den von hald-probe-vide angeforderten Zugriff.
Da nicht davon ausgegangen wird, dass dieser Zugriff von hald-probe-vide benötigt wird, signalisiert dies möglicherweise
einen Einbruchsversuch. Es ist ausserdem möglich, dass diese spezielle Version oder Konfiguration der Anwendung den
zusätzlichen Zugriff verursacht
Zusätzliche Informationen
Quellkontext: system_u:system_r:hald_t:s0
Zielkontext: unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Zielobjekte: @/de/sundtek/mediasocket [ unix_stream_socket ]
Quelle: hald-probe-videQuellpfad: /usr/libexec/hald-probe-video4linuxPort: <Unbekannt>
Host: RPM-Pakete der Quelle: hal-0.5.14-3.fc13
Was ist hier der Vorschlag? SELinux komplett deaktivieren??
-
Erstens bitte einmal http://www.sundtek.de/media/sundtek_installer_development.sh testen.
Sollte dies nicht funktionieren werden wir uns dieses System genauer ansehen.
Alternative ist natuerlich SELinux auszuschalten, jedoch sollte das nicht notwendig sein.
-
Habe da immer noch den selben Fehler mit dem sundtek_installer_development.sh Treiber.
-
Das unter Fedora HALD Video4Linux geblockt wird ist okay, aber es gibt z.b mit Kaffeine ein Codecproblem - welches Fedora intern besteht.
AnalogTV und FM Radio hat mit Fedora 13 auf anhieb funktioniert.
Fuer DVB wuerde bei Kaffeine xine-lib-extras-freeworld benoetigt werden.
(http://www.sundtek.de/images/fc13-small.png) (http://www.sundtek.de/images/fc13.png)
Die Fehlermeldung haben wir direkt an Fedora reported - werden es jedoch auch selber im Treiber nachpflegen.
Der Bug im Bild ist ein allgemeiner Kaffeine Bug unter Fedora 13, dieser wurde bereits weitergeleitet an die jeweiligen Entwickler
Fedora Bugreport:
https://bugzilla.redhat.com/show_bug.cgi?id=629086 (bezueglich der Rules - wurde bereits bei Fedora behoben)
https://bugzilla.redhat.com/show_bug.cgi?id=629095 (Falsche Icons bei kaffeine fuer verschluesselte Sender)
-
Also ein SELinux Problem hab ich definitiv nicht mehr. Ich hab es testweise komplett deaktiviert. Ich hab immer noch kein Bild und Ton mit VLC und ME-TV (DVB).
me-tv -v
Me TV 1.3.2
01.09.2010 20:09:58: Application constructor
01.09.2010 20:09:58: sqlite3_threadsafe() = 1
01.09.2010 20:09:58: Database 'exists'
01.09.2010 20:09:58: Opening database file '/home/user/.local/share/me-tv/me-tv.db'
01.09.2010 20:09:58: Loading UI files
01.09.2010 20:09:59: Application constructed
01.09.2010 20:09:59: Initialising table 'version'
01.09.2010 20:09:59: Required Database version: 6
01.09.2010 20:09:59: Actual Database version: 6
01.09.2010 20:09:59: Me TV database initialised
01.09.2010 20:09:59: StatusIcon constructor started
01.09.2010 20:09:59: StatusIcon constructed
01.09.2010 20:09:59: MainWindow constructor
01.09.2010 20:09:59: MainWindow constructed
01.09.2010 20:09:59: Scanning DVB devices ...
01.09.2010 20:09:59: Opening frontend device: /dev/dvb/adapter0/frontend0
01.09.2010 20:06:47: Failed to write to output channel
01.09.2010 20:06:47: Failed to write to output channel
01.09.2010 20:06:47: Failed to write to output channel
01.09.2010 20:06:47: Failed to write to output channel
01.09.2010 20:06:47: Failed to write to output channel
01.09.2010 20:06:47: Failed to write to output channel
01.09.2010 20:06:47: Failed to write to output channel
01.09.2010 20:06:47: EPG update complete
01.09.2010 20:06:47: Failed to write to output channel
01.09.2010 20:06:47: Failed to write to output channel
01.09.2010 20:06:47: Failed to write to output channel
01.09.2010 20:06:47: Failed to write to output channel
01.09.2010 20:06:47: Failed to write to output channel
01.09.2010 20:06:47: Failed to write to output channel
01.09.2010 20:06:47: Failed to write to output channel
01.09.2010 20:06:47: Failed to write to output channel
01.09.2010 20:06:47: Failed to write to output channel
01.09.2010 20:06:47: Failed to write to output channel
01.09.2010 20:06:47: Failed to write to output channel
me-tv-player (xine): Setting deinterlacer state to false
01.09.2010 20:06:47: Failed to write to output channel
me-tv-player (xine): Setting audio stream to 0
me-tv-player (xine): Setting subtitle stream to -1
me-tv-player (xine): Setting mute state to false
me-tv-player (xine): Setting volume to 100
01.09.2010 20:06:48: Saving channels
01.09.2010 20:06:48: Saving channel 'Das Erste'
01.09.2010 20:06:48: Channel 'Das Erste' saved
01.09.2010 20:06:51: Saving EPG event texts
01.09.2010 20:06:51: EPG events saved
01.09.2010 20:06:51: Saving EPG events for 'HD 1'
01.09.2010 20:06:51: Saving 0 EPG events
01.09.2010 20:06:51: Saving EPG event texts
01.09.2010 20:06:51: EPG events saved
01.09.2010 20:06:51: Saving EPG events for 'ServusTV'
01.09.2010 20:06:51: Saving 0 EPG events
01.09.2010 20:06:51: Saving EPG event texts
01.09.2010 20:06:51: EPG events saved
01.09.2010 20:06:51: Deleting old EPG events
01.09.2010 20:06:51: EPG events saved
01.09.2010 20:06:51: Application destructor complete
01.09.2010 20:06:51: Destroying StreamManager
01.09.2010 20:06:51: Stopping frontend thread
01.09.2010 20:06:51: Stopping frontend thread (/dev/dvb/adapter0/frontend0)
01.09.2010 20:06:51: Thread 'Frontend' marked for termination
01.09.2010 20:06:51: Thread 'Frontend' waiting for join ...
01.09.2010 20:06:51: FrontendThread loop exited (/dev/dvb/adapter0/frontend0)
01.09.2010 20:06:51: Thread 'Frontend' exited
01.09.2010 20:06:51: Thread 'Frontend' joined
01.09.2010 20:06:51: Frontend thread stopped and joined (/dev/dvb/adapter0/frontend0)
01.09.2010 20:06:51: Destroying FrontendThread (/dev/dvb/adapter0/frontend0)
01.09.2010 20:06:51: About to close input channel ...
01.09.2010 20:06:51: Stopping frontend thread (/dev/dvb/adapter0/frontend0)
01.09.2010 20:06:51: Frontend thread stopped and joined (/dev/dvb/adapter0/frontend0)
01.09.2010 20:06:51: FrontendThread destroyed (/dev/dvb/adapter0/frontend0)
bash-4.1# rpm -qa | grep kernel
kernel-devel-2.6.33.8-149.fc13.x86_64
kernel-headers-2.6.34.6-47.fc13.x86_64
kernel-2.6.34.6-47.fc13.x86_64
abrt-addon-kerneloops-1.1.13-2.fc13.x86_64
kernel-devel-2.6.34.6-47.fc13.x86_64
bash-4.1# rpm -qa | grep vlc
mozilla-vlc-1.1.3-1.fc13.x86_64
vlc-1.1.3-1.fc13.x86_64
vlc-core-1.1.3-1.fc13.x86_64
bash-4.1# rpm -qa | grep me-tv
me-tv-1.3.2-1.fc13.x86_64
bash-4.1
-
ok nach dem Testen von Me-TV:
Kurze Zusammenfassung: Me-TV ist derzeit absolut defekt
1. Scannen nach vorgegebener Frequenztabellen funktioniert
In unserem Falle wurde die erste Frequenz gefunden (113000000 Hz/Symrate 6900000/Qam64 - nach der vorgegebenen Scanfile)
Dieser Transponder beinhaltet bei uns die komplette Transponderliste mit allen Frequenzen und Parameter aller anderen Sender.
Laut Logfile /var/log/mediasrv.log ist jedoch ersichtlich das Me-TV diese Transpondertabelle falsch auswertet und eine falsche Symbolrate uebergibt.
Diese werden falsch uebersetzt 0x69000 entspricht laut Spezifikation 6900000 und nicht 430080 (wie von Me-TV angenommen)
Als weiteren Fehler haben wir bemerkt das nach dem Einstellen der Sender welche in der gefundenen Liste aufscheinen der Tuner nicht mehr auf die jeweilige Frequenz gesetzt wird (dies kann mittels /opt/bin/mediaclient manuell gemacht werden z.B /opt/bin/mediaclient -m DVBC -f frequenzinhz -M modulation(Q64 oder Q256 ueblicherweise) -S symbolrate), nach manueller Frequenzkonfiguration konnten die Sender auf dem jeweiligen Transponder auch ausgewaehlt werden.
Die Entwicklung von Me-TV sieht folgendermaszen aus, anfangs wurde mplayer sowie scan aus den dvb-apps extern aufgerufen, die Entwickler wollen nun jedoch diese Funktionalitaet direkt in den Player einbauen - was leider klaeglich fehlschlaegt.
Unser Fedora Core 13 Me-TV DVB-C Bugreport:
https://bugzilla.redhat.com/show_bug.cgi?id=629375
(http://www.sundtek.de/images/metvfedorasmall.png) (http://www.sundtek.de/images/metvfedora.png)
Der VLC Test kommt noch.
Fuer Fedora Core 13 empfehlen wir jedoch vorerst Kaffeine oder VDR.
Nuetzliche Links
* http://www.fedorawiki.de/index.php/Fehlende_Multimediafunktionen_nachrüsten
-
Gibt es schon was Neues zum VLC-Test?. Selbes Problem bei mir unter F14.
-
Haben Sie schon versucht den Videostandard PAL zu setzen? (nicht PAL-B)
Die Videostandardauswahl ist nach wievor defekt bei VLC. Im Auswahlmenue stehen nicht die vom Treiber verfuegbaren Videostandards sondern alle Standards auch welche vom Geraet nicht unterstuetzt werden.
-
wo kann man die Einstellung Videostandard ändern?
-
(http://www.sundtek.de/images/vlc_fedora_small.jpg)
Bitte beachten Sie dieses Thema wird nun gesperrt da dies der alte Treiber ist! Weitere Diskussionen diesbezueglich im neuen Treiberthread weiterfuehren.