Beiträge von Dr.Nop
-
-
Wenn man mal "athcool" in die Suche eingibt findet man viele Threads dazu. Vorsichtig ist aber angebracht, da athcool schon sehr oft Auslöser schwerwiegender Probleme war.
-
Bestimmte Vorgänge lassen sich einfach nicht parallelisieren. Ansonsten eignet sich VDR gut für den SMP Betrieb, da es multithreaded programmiert ist.
-
-
Das DVB Network ist auch ein Forum mit einigen Nordamerikanern, möglicherweise findest du ja da was brauchbares.
-
Ich bin mir nicht 100% sicher, aber ich vermute, dass das VTP Protokoll ähnlich wie FTP die Videodaten über andere, zufällig gewählte Ports verschickt. Mal in der Firewall nachsehen, ob Daten hängen bleiben.
-
Dieser Fehler tritt auf, wenn man noch eine vdrburn-dvd.sh von einer älteren Pluginversion benützt.
-
Ok, hatte vergessen die vdrburn-dvd.sh zu aktualisieren.
-
Wie in diesem Thread zu lesen ist, gibt es möglicherweise noch einen Bug beim Verarbeiten der Aufnahmen.
-
Ich habe in der vdrburn-dvd.sh folgende 2 Zeilen eingefügt:
Code
Alles anzeigen$JAVA_HOME/bin/java -Djava.awt.headless=true \ -jar $PROJECTX_HOME/ProjectX.jar \ -ini $CONFIG_PATH/ProjectX.ini \ $CUT -id $USED_TRACKS,0x1f,0x20 \ -demux -out $MPEG_DATA_PATH -name vdrsync \ $(ls $MPEG_TMP_PATH/convert/[0-9][0-9][0-9].vdr) + rm -f "$MPEG_DATA_PATH/vdrsync0.mpa" + ln -s "$MPEG_DATA_PATH/vdrsync.mpa" "$MPEG_DATA_PATH/vdrsync0.mpa" if [ -e "$MPEG_DATA_PATH/vdrsync[1].mpa" ]; then rm -f "$MPEG_DATA_PATH/vdrsync1.mpa" mv "$MPEG_DATA_PATH/vdrsync[1].mpa" "$MPEG_DATA_PATH/vdrsync1.mpa" fi if [ -e "$MPEG_DATA_PATH/vdrsync[2].mpa" ]; then
-
Ich hatte möglicherweise das gleiche Problem, wie du. Schau mal welche Dateien in dem VDRSYNC.x Verzeichnis sind, bei dem mplex hängen bleibt. Vorallem ob die Tondateien auch genau so benannt sind, wie in den mplex Parametern.
-
Bei neusten FFMPEG Versionen wurde FFMPEG_VERSION zu LIBAVFORMAT_VERSION geändert. Das Format der Versionsnummer wurde auch verändert.
In der avformat.h mal die Zeile #define FFMPEG_VERSION xxxx einfügen und verschiedene Formate durchprobieren, irgendwann wird es gehen.
-
Auf http://www.linux-ntfs.org/ gibt es NTFS Treiber der 3. Generation, welche trotz ²-Stadiums problemlos funktionieren. Es ist allerdings FUSE nötig.
-
Zum Beispiel, das Display unterstützt diese Auflösung garnicht, sondern nur 1024x768 o.ä.. Es könnte auch die Auflösung unterstützen aber das Bild vorher auf 1024x768 runterrechnen und wieder auf 1366x768 hochziehen (z.B. Medion TFTs machen das). Falls du später mal vor hast, mit dem XINE Plugin oder anderen das Display 1:1 via DVI anzusteuern, wäre eine Fehlfunktion doch ziemlich ärgerlich.
-
Überprüf auch mal, ob sich das Display mit seiner nativen Auflösung am DVI Port fehlerfrei betreiben lässt. Üblicherweise geht das vorallem bei billigen nicht.
-
Um gescheit die Wirkleistung eines Schaltnetzteiles zu messen, solltest du ein Messgerät mit "True-RMS" haben, welche allerdings nicht für 20€ im Baumarkt verramscht werden.
-
Sicherlich kommt xine damit klar, schließlich ist es ja xine welches das Bild verändert. Es wird halt mit jedem mal ein bischen größer. Einfach mal ausprobieren.
-
Es wäre auch für mich äußerst wünschenswert, wenn die Portalverwaltung das einbauen könnte. Konqueror will nämlich auch immer attachment.php speichern.
-
Ich habe fast noch nie mit welchen Netzwerkkarten auch immer Probleme gehabt. Einzige Ausnahme ein VIA onboard NIC, die Probleme wurden allerdings durch ein minderwertiges Netzteil verursacht.
-
Nun, ZoomInY zieht das Bild schrittweise auf die volle Höhe, ZoomReset stellt wieder auf normal zurück. remote und button müssen auf die jeweilige Fernbedienung angepasst werden.