Ich habe hier gerade eine alte DVB-S2 Karte:
05:01.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Subsystem: Technotrend Systemtechnik GmbH S2-3200
Flags: bus master, medium devsel, latency 32, IRQ 11
Memory at f7900000 (32-bit, non-prefetchable) [size=512]
in ein älteres Mainboard eingebaut (core i5) mit Debian 12.5. Da taucht aber kein Device unter /dev/dvb auf. Eigentlich sollte da doch weder zusätzlicher Treiber oder Firmware erforderlich sein.
Kein bookworm, das stimmt. Verstehe gar nicht, wie ich das übersehen habe. Wäre also
die Empfehlung von Euch?
Aber ich sehe doch die WEB-Seiten:
https://blog.e-tobi.net/pages/repositories ... usw
Oder kann sein Server einfach nur kein IPv6?
Ich hatte gerade versucht, das Repository von e-tobi auf einer bookworm installation zu benutzen.
gpg --keyserver keyring.debian.org --recv-keys D62E4F5B041390BC
gpg --export D62E4F5B041390BC | sudo gpg --dearmor -o /usr/share/keyrings/packages.e-tobi.net.gpg
/etc/apt/sources.list.d/e-tobi.list:
deb [arch=amd64 signed-by=/usr/share/keyrings/packages.e-tobi.net.gpg] http://packages.e-tobi.net/vdr-experimental bookworm base vdr-multipatch
und bekomme die Fehlermeldung nach apt update:
OK:2 http://security.debian.org/debian-security bookworm-security InRelease
OK:3 http://deb.debian.org/debian bookworm InRelease
OK:4 http://deb.debian.org/debian bookworm-updates InRelease
Ign:1 https://packages.e-tobi.net/vdr-experimental bookworm InRelease
Fehl:5 https://packages.e-tobi.net/vdr-experimental bookworm Release
404 Not Found [IP: 2a01:4f8:1c0c:4402::1 443]
Paketlisten werden gelesen… Fertig
E: Das Depot »http://packages.e-tobi.net/vdr-experimental bookworm Release« enthält keine Release-Datei.
N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere Art durchgeführt werden, daher ist es standardmäßig deaktiviert.
N: Weitere Details zur Erzeugung von Paketdepots sowie zu deren Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8).
Ich habe mit Interesse und wiederholt alles noch einmal gelesen, was hier in den letzten Tagen zu meiner Frage geschrieben worden ist. Es ist unglaublich! Da gibt es diese große, motivierte Entwicklergemeinde des VDR. Aber wie sieht die Dokumentation und die Präsentation des Ganzen aus:
1.) Die Beschreibungen in den Distributionen: Arch Linux: https://wiki.archlinux.org/index.php/VDR, Debian: https://wiki.debian.org/VDR, Ubuntu: https://wiki.ubuntuusers.de/VDR/ und das Stärkste: Fedora: https://fedoraproject.org/wiki/HTPC - genau eine Zeile, das es VDR gibt, ohne Links. Diese Beschreibungen sind alle hoffnungslos veraltet. Überladen mit unnützen Details. Fehlende Links.
2.) Das VDR-Wiki. https://www.linuxtv.org/vdrwiki/index.php/Introduction last modified on 2 November 2010. https://www.linuxtv.org/vdrwiki/index.php/News: vdr-1.7.31 released (Eine Einzige). https://www.linuxtv.org/vdrwiki/index.php/VDR_Wiki:Portal last modified on 19 December 2005. Das muss man doch nur Anfassen und hier was von HEVC und DVB-T2 reinschreiben. Und mal was löschen.
Copperhead. Wollen wir nicht mal zusammen die VDR-Beschreibung im Arch Linux aktualisieren (und kürzen)? Ich bin auch bereit, Vdr4Arch regelmäßig bei mir zu installieren und über die Probleme zu berichten. Vielleicht im VDR-Wiki?
Ich hatte erfolgreich vdr4arch nach
https://github.com/VDR4Arch/vd…4Arch-Installation-(en_US)
installiert. Jetzt wollte ich mich wieder damit beschäftigen, aber:
- der vdr4arch-keyring ist nicht mehr verfügbar
- das Repository http://creimer.net/vdr4arch/repo/.. gibt es nicht mehr
Aber http://creimer.net/vdr4arch/repos/.. Oder soll man das eher über AUR installieren?
Weiß den keiner, was mit e-tobi.net passiert ist? Da kommt dieses "404 - Not Found". Das ist aber doch eine Seite, die von seinem Web-Server kommt:
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>404 - Not Found</title>
</head>
<body>
<h1>404 - Not Found</h1>
</body>
</html>
Ich mache so was immer mit Handbrake: https://handbrake.fr/. Damit aus mehreren .ts-Dateien eine wird kann man die mit Avidemux: http://fixounet.free.fr/avidemux/ zusammen führen und schneiden. Einfach mit Avidemux die erste .ts-Datei anklicken, dann fragt er, ob er alle laden soll. Beide Programme gibt es für Windows und Linux.
Viele Grüße
Karl-Heinz
Ich hab ein ganz merkwürdiges Problem mit dem xine. Die Datei $HOME/.xine/config ist nach jedem Booten in dem Zustand:
#
# xine config file
#
.version:2
# Entries which are still set to their default values are commented out.
# Remove the '#' at the beginning of the line, if you want to change them.
und das, was ich hier konfiguriert hatte, findet sich in config~. Das passiert offensichtlich beim Herunterfahren des Rechners (wenn ich mit einer anderen LinuX-Installation auf dem Rechner die Datei ansehe ist die so).
Kann mir jemand sagen, wie das kommt und wie ich meine Konfiguration behalten kann?
Gruß
Karl-Heinz
---------------------------
ubuntu karmic, vdr 1.7.9 the-vdr-team, xine (und xineliboutput) plugin -> xine-ui, TT3200, NVidia 9600GT
Die Treiber von s2-liplianin bieten das DVB driver API version 5.1. Ich hab in dvbdevice.h mal geändert:
#if DVB_API_VERSION != 5 
DVB_API_VERSION_MINOR != 1
#error VDR requires Linux DVB driver API version 5.0!
#endif
Dann läuft die Kompilation so durch.
Gruß
Karl-Heinz
Ich sehe mit einer Debian Lenny und einer Installation wie hier beschrieben auf einem 16:10 Display fern. Was mich stört, sind die schwarzen Streifen oben und unten. Ganz besonders störend ist das, wenn es Sendungen im Letterbox-Format gibt, wie jetzt die Star Trek Filme.
Beim dvbviewer kann man Zoom, Höhe und die Breite einfach stufenlos verstellen. Geht das mit VDPAU nicht? Was ich wirklich gerne hätte wäre ein komplett ausgefüllter Schirm. Dann fehlt zwar ein bisschen in der Breite, aber das stört nicht, finde ich.
Gruß
Karl-Heinz
Ich hab tatsächlich auch eine Lösung für mein Problem gefunden. Die Seite:
http://www.playtool.com/pages/dvitrouble/dvitrouble.html
finde ich sehr gut. In meinem Fall ist die Lösung, die "Source"-Taste an meinem Display zu drücken. Dann schaltet das Display auf "Digital" und die Störungen sind weg..
Gruß
Karl-Heinz
Aber ich habe doch nicht das Problem, das die X-Konfiguration in dieser Auflösung nicht funktionieren würde. Das Display wird vollkommen falsch angesteuert.
Die Auflösung von meinem Display ist 1680x1050. Die ist auch immer richtig - auch wenn dir merkwürdigen Farbsäume da sind. In der Anlage schicke ich auch mal meine aktuelle /etc/X11/xorg.conf.
Gruß
Karl-Heinz
kh@john:/etc/X11$ more xorg.conf
# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig: version 1.0 (buildmeister@builder58) Thu Jun 5 00:08:24 PDT 2008
# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings: version 1.0 (buildmeister@builder26) Thu Feb 14 18:14:18 PST 2008
Section "ServerLayout"
Identifier "Layout0"
Screen 0 "Screen0" 0 0
Screen 1 "Screen1" RightOf "Screen0"
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "Mouse0" "CorePointer"
EndSection
Section "Files"
RgbPath "/usr/X11R6/lib/X11/rgb"
EndSection
Section "Module"
Load "dbe"
Load "extmod"
Load "type1"
Load "freetype"
Load "glx"
EndSection
Section "ServerFlags"
Option "Xinerama" "0"
EndSection
Section "InputDevice"
# generated from default
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/psaux"
Option "Emulate3Buttons" "no"
Option "ZAxisMapping" "4 5"
EndSection
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "de"
Option "XkbVariant" "nodeadkeys"
EndSection
Section "Monitor"
Identifier "Monitor0"
VendorName "Unknown"
ModelName "CRT-0"
HorizSync 30.0 - 107.0
VertRefresh 48.0 - 120.0
Option "DPMS"
EndSection
Section "Monitor"
Identifier "Monitor1"
VendorName "Unknown"
ModelName "LG L226WTQ"
HorizSync 28.0 - 83.0
VertRefresh 56.0 - 75.0
EndSection
Section "Device"
# Option "UseDisplayDevice" "DFP-0, DFP-1"
# Option "ConnectedMonitor" "DFP"
# Option "UseDisplayDevice" "DFP"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
EndSection
Section "Device"
Identifier "Videocard0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName "GeForce 8600 GTS"
BusID "PCI:1:0:0"
Screen 0
EndSection
Section "Device"
Identifier "Videocard1"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName "GeForce 8600 GTS"
BusID "PCI:1:0:0"
Screen 1
EndSection
Section "Screen"
# Removed Option "metamodes" "1600x1200 +0+0"
Identifier "Screen0"
Device "Videocard0"
Monitor "Monitor0"
DefaultDepth 24
Option "TwinView" "0"
Option "TwinViewXineramaInfoOrder" "CRT-0"
Option "metamodes" "CRT: 1600x1200 +0+0"
SubSection "Display"
Depth 24
EndSubSection
EndSection
Section "Screen"
Identifier "Screen1"
Device "Videocard1"
Monitor "Monitor1"
DefaultDepth 24
Option "TwinView" "0"
Option "metamodes" "DFP: nvidia-auto-select +0+0"
SubSection "Display"
Depth 24
Modes "nvidia-auto-select"
EndSubSection
EndSection
Ich hab ein vertracktes Problem auf der gleichen Ebene. Ich habe eine NVidia 7800 an der ein 22" LG TFT und einem 20" Sony Monitor hängen. Das 22" TFT ist über ein 10m DVI-Verlangerungkabel an den Rechner angeschlossen (der ein Stockwerk höher steht). Der nachfolgend beschriebene Fehler tritt auch auf, wenn der analoge Monitor nicht angeschlossen ist.
Wenn ich den Rechner einschalte bekomme ich manchmal (eher meistens) ein Bild, das von senkrechten grünen Streifen durchzogen ist, so das der Text auf dem Bildschirm kaum lesbar ist. Wenn der X-Server dann hochkommt, ist das Bild flimmernd und kaum zu ertragen. Wenn ich (mit dem propietären NVidia Treiber, NVIDIA-Linux-x86_64-173.14.09 auf Debian "sid") die Parameter
Option "UseDisplayDevice" "DFP-0"
Option "ConnectedMonitor" "DFP-0"
benutze, ändert das nichts.
Ist das Bild beim Einschalten normal, ist das Bild gut und bleibt auch gut, auch wenn ich stundenlang fernsehe. Schalte ich das TFT einmal kurz aus und wieder ein, ist sofort der oben beschriebene Fehler da.
Ich stelle mir vor, das der Fehler dadurch entsteht, das die Karte das TFT mit analogen Signalen ansteuert, weil durch das lange Kabel das TFT nicht erkannt wird. Die "analoge" Ansteuerung also als Fallback, weil die Karte nicht weiter weiss.
Weiss nicht jemand eine Methode - das gleiche müste ja beim KVM-Switch auftreten - wie man der NVidia-Karte sagen kann: steuer DVI an? Oder muss ich mir mal ein teueres Kabel kaufen? Und wenn ja, welches?
Der gleiche Fehler tritt überigens mit einem anderen Rechner und einer 8600 GTS genauso auf.
Gruß
Karl-Heinz
Ich hatte mit fürs HDTV ein ASUS P5B mit einem Intel Core2 Duo E6750 2x2.67GHz gekauft, in der Hoffnung, so zu ruckelfreiem Fernsehen zu kommen. Mein LinuX hierfür ist ein Debian Etch für AMD64 mit selbst kompiliertem Kernel 2.6.23.9. Unter "make menuconfig" hatte ich
Processor family (Intel Core2 / newer Xeon)
Als Prozessor ausgewählt. Die Frage ist natürlich, ob mir das bei meinen 2 GB Hauptspeicher überhaupt etwas bringt (ausser Ärger).
Mit einer 32 bit Debian Installation auf diesem Rechner habe ich das Aussetzen des Tons bisher nicht beobachtet, obwohl fast die gleiche HDTV-Beta-Installation da drauf ist.
Gruß
Karl-Heinz
Bei mir ist das anders: Der Ton ist manchmal einfach beim Zappen (auf einen HDTV oder einen mormalen Sender) weg oder kommt gar nicht, wenn ich xine starte. Ich sehe keinen Zusammenhang mit Dolby Digital.
Ich hab ein debian etch stable mir einem kernel 2.6.23.9 von www.de.kernel.org. Das HDTV Beta habe ich vor ca. 10 Tagen neu nach der Mail von Reinhard vom 24 November:
[vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.12
installiert. Mir sind keine besonderen Warnings aufgefallen.
Ich hab schon alles mögliche probiert um dauerhaft zu Sound zu kommen. Gestern habe ich eine Soundkarte in den Rechner eingebaut, falls es irgendwas mit den ALSA-Treiber zu tun haben sollte. Keine Änderung. Ich hab bestimmt jeden verdammten Regler bei KMix und bei Alsamixer durchprobiert. Der Tom kommt manchmal auch wieder, wenn ich /usr/bin/artsd daemon neu starte.
Hat jemand eine Idee, wie man das debuggen könnte? Das die ffmpeg daran Schuld ist glaube ich nicht so recht. Manchmal kan ich den Ton mit
/etc/init.d/alsa-utils restart
wiederbekommen (das ist das gleiche, als wenn man alsaconf durchlaufen lassen würde).
Gruß aus Bremen
Karl-Heinz
Unter Softdevice - Video Out sind alle Einstellungen auf 50: Helligkeit, Kontrast, Hue und Saturation. Wenn ich Hue auf 100 ändere, sehen die Farben ganz OK aus.
Ich lese gleich mal nach, was das heissen soll. Da habe ich eine "Lücke" - bildungsmässig.
Danke.
Also das "_t" aus der Typendeklaration herauslöschen. Ja das klappt! make plugins läuft fehlerfrei durch. Und ich kanns auch starten.
Wobei jetzt das nächste "kleine Problem" da ist: Die Farben stimmen nicht (das hatte ich auch schon bei der 0.2.2). Die Sättigung ist zu gering und die Farben sind falsch. Wenn man das OSD auf "pseudo" umschaltet sind die Farben des OSD OK (nicht des Bildes). Schaltet man das OSD auf "software" ist rot dann dunkelgrün, grün hellrot u.a.m.
Sowas habe ich auch schon beim xine-plugin gesehen (in zusammenhang mit XvMC). Eine Einstellmöglichkeit, das zu ändern, sehe ich nicht.
Ich benutze eine NVidia FX 5200 (die abgelegte Grafikkarte von meinem Sohn). Der Treiber ist: NVIDIA-Linux-x86_64-1.0-8756-pkg2.run
Karl-Heinz
Rechner: Debian sarge, Athlon 64, ffmpeg aus cvs, softdevice: nur Xv ausgewählt
Da mit dem CVS hatte ich vorher auch schon probiert. Das mit dem UpDate hat jetzt auch geklappt:
eric:/soft/vdr-1.4.0/PLUGINS/src# cvs -d:pserver:anonymous@cvs.softdevice.berlios.de:/cvsroot/softdevice update
? softdevice-0.2.3/.dependencies
? softdevice-0.2.3/config.h
? softdevice-0.2.3/config.mak
cvs server: Updating softdevice-0.2.3
U softdevice-0.2.3/.cvsignore
M softdevice-0.2.3/Makefile
P softdevice-0.2.3/configure
P softdevice-0.2.3/video-dfb.c
Danke. Nur - am Problem ändern tut das nichts. Kann das an meiner 64 Bit Installtion liegen?
Karl-Heinz
