ZitatOriginal von samc
nach dem 1. Kanalwechsel bleibt das Bild dunkel.
runterfahren, Netzschalter aus, 10 sek. warten, neu booten
Muss ich inzwischen bei jeder Neuinstallation eines ivtv-Treibers machen. nur reboot alleine reicht nicht.
ZitatOriginal von samc
nach dem 1. Kanalwechsel bleibt das Bild dunkel.
runterfahren, Netzschalter aus, 10 sek. warten, neu booten
Muss ich inzwischen bei jeder Neuinstallation eines ivtv-Treibers machen. nur reboot alleine reicht nicht.
Zitatrunterfahren, Netzschalter aus, 10 sek. warten, neu booten
natsächlich, an sowas hab ich bisher nie geglaubt...man lernt nie aus
aber auch mit der alten fw: flackern
-> muss am Treiber liegen
...
wäre schon, wenn alle, die dieses Flackern im oberen Drittel/Viertel haben, mal eine Meldung in die ivtv-devel ML posten würden. Ich habe das dort mal als größtes Problem, das der Treiber noch hat, bezeichnet, aber Hans Verkuil scheint das nicht ernst zu nehmen.
Es ist mir nach wie vor unerklärlich, weshalb manche das Problem ständig haben, und andere nie. Es ist definitiv auf der Encoderseite zu suchen, so dass mythtv-user eigentlich auch betroffen sein müssten. An der Anwendung kann es eigentlich auch nicht liegen, denn mit dem analogtv-Plugin tritt es auch auf. Zu ptv kann ich nichts sagen, da das Plugin sich schon seit geraumer Zeit nicht mehr mit aktuellen vdr-Versionen kompilieren lässt.
wirbel: Hast Du da noch was vor ? Eine Weiterentwicklung von ptv würde m.E. aber nur Sinn machen, wenn es auch auch vbi (Videotext) könnte.
ZitatEs ist mir nach wie vor unerklärlich, weshalb manche das Problem ständig haben, und andere nie
also ich gehoere in diesem Fall mal ausnahmsweise zu denen, die das Problem nur selten haben. Ausserdem hat bei mir, als ich das letzte mal das Flackern vor vielleicht ca. 2 Wochen hatte (Kiste laeuft 24/7) ein Treiber (Un)Load gereicht. Auch laeuft die 0.8.0 bei mir bis jetzt ohne erkennbare Probleme. Das alles gilt fuer 2 VDRs, die ich mit PVR350 (Kaufabstand ca 1/2 Jahr) am laufen habe. Vielleicht gibt es irgendwelche marginalen HW- Unterschiede zwischen den Kartenversionen, die wir erst klaeren muessten.
zum Treiberentladen musst Du doch aber erst vdr stoppen?
mein problem ist, dass auch bei beendetem vdr sich die ivtv-Treiber nicht entladen lassen, weil sie busy sind. Auch ein modprobe -r tut´s nicht. Nur wenn man die einzelnen, voneinander abhängigen Module (saa7127, ... saa7115, ...) in der richtigen Reihenfolge einzeln entlädt, dann kann man zum Schluß auch ivtv und ivtv_fb entladen.
Zitatzum Treiberentladen musst Du doch aber erst vdr stoppen?
ja klar. Das mache ich bevorzugt z.B. mit SIGQUIT weil mir dann mein wrapper Script (runvdr based) das Entladen/Laden aller VDR-relevanten Module automatisch uebernimmt.
Zitatbei beendetem vdr sich die ivtv-Treiber nicht entladen lassen
das ist ein sehr interessanter Hinweis! Vielleicht kommen wir damit der Loesung ein wenig naeher.
ZitatNur wenn man die einzelnen, voneinander abhängigen Module (saa7127, ... saa7115, ...) in der richtigen Reihenfolge einzeln entlädt
das mache ich aber ohnehin immer. Die Module
entladen bei mir durch 'modprobe -r' alleine nie. Offenbar sind da die Dependencies irgendwie falsch. Ich benutze allerdings die PVR350 nicht allein im Geraet sondern immer zusammen mit ner S2300. Damit habe ich am Ende exakt diese Ladereihenfolge (bei Verwendung der Builtin DVB Treiber)
Laden:
modprobe dvb-ttpci
modprobe ivtv
ergibt diese zusaetzl. Module in 'lsmod'
msp3400 33568 0
saa7127 12436 0
saa7115 16528 0
tda9887 17936 0
tuner 55852 0
ivtv 201616 0
i2c_algo_bit 9992 1 ivtv
tveeprom 15632 1 ivtv
dvb_ttpci 103236 0
l64781 7940 1 dvb_ttpci
saa7146_vv 49664 1 dvb_ttpci
video_buf 25860 1 saa7146_vv
saa7146 18824 2 dvb_ttpci,saa7146_vv
v4l1_compat 14596 2 ivtv,saa7146_vv
v4l2_common 15744 3 msp3400,tuner,saa7146_vv
videodev 9600 2 ivtv,saa7146_vv
ves1820 6788 1 dvb_ttpci
stv0299 11400 1 dvb_ttpci
dvb_core 80168 2 dvb_ttpci,stv0299
tda8083 6660 1 dvb_ttpci
stv0297 8960 1 dvb_ttpci
sp8870 7948 1 dvb_ttpci
ves1x93 7172 1 dvb_ttpci
ttpci_eeprom 2816 1 dvb_ttpci
Entladen:
modprobe -r ivtv
rmmod tda9887
rmmod saa7127
rmmod saa7115
rmmod msp3400
rmmod tuner
modprobe -r dvb-ttpci
Alles anzeigen
Zitatund ivtv_fb entladen.
was ist das fuer ein Modul? Das kenn/benutz ich gar nicht.
So, hab jetzt noch ein bischen weiterprobiert:
bei mir läßt sich das Falckern beseitigen durch schließen und wieder öffnen von /dev/videox
Hab den Code ein bischen erweitert:
bei jedem Ändern der Plugineinstellungen im OSD wird
ohnehin ein ReInit ausgeführt, der schrieb aber nur die Konfig neu in die Karte, jetzt mach ich auch noch device auf/zu und das Flackern ist weg.
Probier mal ob das auch beim Kanalwechsel eingebaut werden kann...
Grüße,
Simon
pvrinput oder analogtv ?
her mit dem patch
pvrinput
ruf jetzt auch beim Kanalwechsel auf, funktionieren tut das Plugin noch, ob das Flackern jetzt beim Wechsel "resettet" wird weiss ich noch nicht, ist bisher nicht wieder aufgetreten.
Ach ja der Kanalwechsel ist ein bsichen unsauberer, aber find ich nicht so schlimm wie flackern
Also weg mag mitprobieren?
device.c:
In dieser Methode ergänzen:
void cPvrDevice::ReInit(void)
{
+ delete readThread;
+ close(video_fd);
+ char devName[64];
+ sprintf(devName, "/dev/video%d", number);
+ video_fd = open(devName, O_RDWR);
+ if (video_fd < 0)
+ {
+ log(0, "Error opening video device %s: %s", devName, strerror(errno));
+ }
+
+ readThread = new cPvrReadThread(video_fd, vbi_fd, tsBuffer, &mutex);
+ SetVideoNorm(videoNormPAL);
SetVideoNorm(lastNorm);
SetCodec();
SetVideoSize(720, 576);
Und in dieser:
bool cPvrDevice::OpenDvr(void)
{
log(3, "cPvrDevice::OpenDvr");
delivered = false;
dvrOpen = true;
dvrOpenTime = cTimeMs::Now();
+ ReInit();
+
return true;
}
Der 2. Teil ist noch nicht verifizeirt, der 1. schon
Grüße Simon
ZitatEs ist definitiv auf der Encoderseite zu suchen
das ist zumindest bei mir auch so, da das Problem hier, wenn ueberhaupt dann nur mit xine oder FF Decoder auftritt.
ich denke gar nicht mal, dass es be jedem Kanalwechsel erforderlich ist. Ob man das Auftreten des Flackern damit verhindert, ist ja noch nicht bewiesen. Es durch Umschalten beheben zu können, ist zwar auch praktisch, aber dazu sollte ein Aufruf der Plugineinstellungen eigentlich auch reichen. Vielelicht kannst Du das ähnlich wie die Änderung von Helligkeit, Kontrast etc. (was im vdr-Hauptmenü einstellbar ist) dort als ein Art "reset" einbauen ? dann braucht man sich nicht bis in die Plugin-Einstellungen durchhangeln
ZitatOriginal von sparkie
das ist zumindest bei mir auch so, da das Problem hier, wenn ueberhaupt dann nur mit xine oder FF Decoder auftritt.
es tritt auch bei Ausgabe über die PVR350 (pvr350-Plugin) auf.
Zitatich denke gar nicht mal, dass es be jedem Kanalwechsel erforderlich ist.
ich konnte das Flackern so reproduzieren:
1) mehrmals die Einstellungen im OSD apgespeichert durch Drücken von OK -> Einst. wieder aufgerufen -> OK
2) Vehementes Kanalwechseln
3) mir ist wieder eingefallen wo ich schon vor dem VDR schlimmes Flackern hatte: hab mein damaliges Aufnahmescript um VPS Erkennung erweitert, also erst wurde getuned, dann vbi ausgelesen bis der Film anfing und dann Aufgenommen. Hat funktioniert, aber 50% der Filme verflackert.
4) Erfahrungswert von Früher: Störugen im Signal haben *manchmal* das Flacker verursacht.
(Hab das auch grad reproduzeirt, solange Antennenstecker rein/raus/hin/her bis es da war bei eh schon schlechtem Sender)
-> daraus schließe ich, dass es meist auftritt, wenn der Encode irgendwie "gestört" wird, nicht aber bei sauberem Signal; ein Kanalwechsel ist so eine Störung, da ja kein gültiges Videosignal anliegt.
Will man mit der Karte Aufnehmen (so wie ich) sollte der Reset bei jedem Kanalwechsel wohl
erfolgen...solange keiner andere "Nebenwirkungen" bemerkt...
ZitatVielelicht kannst Du das ähnlich wie die Änderung von Helligkeit, Kontrast etc. (was im vdr-Hauptmenü einstellbar ist) dort als ein Art "reset" einbauen ?
Das würd ich dir gern machen aber meine VDR-Programmierkenntnisse sind da nicht ausreichend, müsst ich mich auch erst einlesen...weiss das vielleicht jemand? Müsste nur cPvrDevice::ReInitAll(); per Menüeintrag aufgerufen werden...
Alternativ kannst du ja auch eine Userkey belegen, die genau die Setupseite des Plugins aufruft und das dann mit OK MENU beenden.
aber jetzt sollten erst mal mehrere testen
Grüße,
Simon
ZitatOriginal von samc
Alternativ kannst du ja auch eine Userkey belegen, die genau die Setupseite des Plugins aufruft und das dann mit OK MENU beenden.
hört sich interessant an, kannst Du das mal genauer beschreiben, wie man das macht ?
Zitathört sich interessant an, kannst Du das mal genauer beschreiben, wie man das macht ?
in die keymacros.conf eintragen.
erst in remote.conf eine Key mit "LIRC.User1 <lirckey>" definieren und dann in die keymacros.conf:
"User1 Menu 6 1 2 3 4" oder sowas, eben die Zahlen die du drückst damit du ins config-Menü kommst.
Dann kannst du ja mit <lirckey> direkt das config Menü aufrufen. Sobald es da ist wieder beenden und in dem Moment wird der ReInit aufgerufen; zusammen mit dem 1. Teil meines "patches" wird das device geschlossen und wieder geöffnet und dann gehts bei mir wieder.
Nochwas wollt ich dich fragen:
Hast ja vorher mal beschrieben, dass du ivtv nicht entladen kannst bei geschlossenem vdr. Hast du vielleicht einen vbi proxy (zvbi) oder sowas laufen?
grüße,
Simon
ZitatAlles anzeigenOriginal von samc
in die keymacros.conf eintragen.
erst in remote.conf eine Key mit "LIRC.User1 <lirckey>" definieren und dann in die keymacros.conf:
"User1 Menu 6 1 2 3 4" oder sowas, eben die Zahlen die du drückst damit du ins config-Menü kommst.
Dann kannst du ja mit <lirckey> direkt das config Menü aufrufen. Sobald es da ist wieder beenden und in dem Moment wird der ReInit aufgerufen; zusammen mit dem 1. Teil meines "patches" wird das device geschlossen und wieder geöffnet und dann gehts bei mir wieder.
das probiere ich gleich aus. Ich habe pvrinput mit dem ersten Patch versehen, und ndas auftretende Flackern habe ich sofort mit einem Aufruf der Plugin-Optionen + ok + schließen beseitigen können ! Danke !!!
ZitatNochwas wollt ich dich fragen:
Hast ja vorher mal beschrieben, dass du ivtv nicht entladen kannst bei geschlossenem vdr. Hast du vielleicht einen vbi proxy (zvbi) oder sowas laufen?
da ich nicht mal weiss, was das ist , vermutlich nicht
Es hat übrigens die letzten 48 Stunden umfangreiche Änderungen im ivtv-Treiber gegeben (trunk). Für pvrinput sollte das keine Auswirkungen haben, aber die Nutzer des pvrinput-Plugins werden in die Röhre schauen. Es wurden sämtliche IOC_S ioctls entfernt (z.B. IOC_S_START_DECODE) sowie die firmware api calls. Das pvr350-Plugin nutzt standardmäßig aber beides. Insbesondere das Stopen + Startend es Decoders geht mit fwapi calls erheblich schnelelr als mittels IOC_STOP_DECODE und IOC_START_DECODE
ZitatIch habe pvrinput mit dem ersten Patch versehen, und ndas auftretende Flackern habe ich sofort mit einem Aufruf der Plugin-Optionen + ok + schließen beseitigen können ! Danke !!!
Das reicht doch erstmal, oder?
Zitatda ich nicht mal weiss, was das ist , vermutlich nicht großes Grinsen
Weiss es selber nicht genau was zvbi eigentlich kann...aber es stört in diesem Fall
ZitatEs hat übrigens die letzten 48 Stunden umfangreiche Änderungen im ivtv-Treiber gegeben (trunk). Für pvrinput sollte das keine Auswirkungen haben, aber die Nutzer des pvrinput-Plugins werden in die Röhre schauen. Es wurden sämtliche IOC_S ioctls entfernt (z.B. IOC_S_START_DECODE) sowie die firmware api calls. Das pvr350-Plugin nutzt standardmäßig aber beides. Insbesondere das Stopen + Startend es Decoders geht mit fwapi calls erheblich schnelelr als mittels IOC_STOP_DECODE und IOC_START_DECODE
Ich hab nur eine PVR250, also gar keine Ahnung davon, sorry.
Es muss aber ja ohnehin nicht der neueste Treiber sein, oder? Bin mir auch gar nicht sicher, dass das Flackern am Treiber liegt, eher an der Firmware; der Treiber sollte es vielleicht erkennen/verhindern und tuts nicht?
Grüße,
Simon
PS: Bei mir bis jetzt kein Flackern, werd nochmal in ein paar Tagen berichten...
Moin!
Noch benutze ich eine 0.4er-Version von ivtv und Kernel 2.6.14, da da ja noch beim Kanalwechsel ein eventuelles Flackern verschwindet. Ich programmier dann immer eine 5-Minuten-Aufnahme vor den eigentlichen Aufnahmen, um dann einen Kanalwechsel vor der Aufnahme zu erzwingen.
Dass das Flackern an einem schlechten Signal liegt, könnte auch erklären, warum das Überspielen von alten VHS-Bändern das Flackern hervorruft, wenn mal eine Stelle kommt, wo das Band nicht mehr ganz in Ordnung ist.
Sollte es also einen aktuellen Kernel mit entsprechend gepatchtem ivtv geben, so dass beim Kanalwechsel das Flackern wieder verschwindet, bin ich gerne bereit, es zu testen.
Außerdem könnte ich mal versuchen, meine TV-Verkabelung auf Vordermann zu bringen, damit das Signal besser wird... Ich hab nämlich bei Sat1 (161,25 MHz) ein schlieriges Bild (bei der PVR und bei meinem neuen Fernseher), der alte Videorekorder und ein alter Fernseher im Schlafzimmer liefern allerdings ein sauberes Bild. Haben vielleicht moderne Tuner bei bestimmten Frequenzen ein Problem?
Naja, ich hab hier noch einen Signalverstärker mit zwei Ausgängen rumliegen, den werde ich mal als erstes in die Reihe schalten.
mini.
P.S.: Ich hatte mal den 2.6.15er Kernel probiert, da hab ich es aber nicht geschafft, dass meine PVR150 MCE vernünftig erkannt wurde. Unten ist die Meldung unter ivtv 0.4.1/2.6.14. Gibt es bekannte Probleme mit meinen Tuner?
ivtv: ==================== START INIT IVTV ====================
ivtv: version 0.4.1 (development snapshot compiled on Sa 29 Okt 2005 16:05:48 CEST) loading
ivtv: Linux version: 2.6.14 386 gcc-3.3
ivtv: In case of problems please include the debug info
ivtv: between the START INIT IVTV and END INIT IVTV lines when
ivtv: mailing the ivtv-devel mailinglist.
ivtv0: Autodetected WinTV PVR 150 card (iTVC16 based)
PCI: Enabling device 0000:01:0b.0 (0014 -> 0016)
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 3
PCI: setting IRQ 3 as level-triggered
ACPI: PCI Interrupt 0000:01:0b.0[A] -> Link [LNKD] -> GSI 3 (level, low) -> IRQ 3
ivtv0: i2c attach to card #0 ok [client=tveeprom, addr=50]
tveeprom 2-0050: Hauppauge model 26559, rev C260, serial# 7735902
tveeprom 2-0050: tuner model is LG S001D MK3 (idx 60, type 38)
tveeprom 2-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/K) (eeprom 0x74)
tveeprom 2-0050: audio processor is CX25843 (idx 37)
tveeprom 2-0050: decoder processor is CX25843 (idx 30)
tveeprom 2-0050: has radio, has no IR remote
tuner (ivtv): chip found at addr 0xc2 i2c-bus ivtv i2c driver #0
ivtv0: i2c attach to card #0 ok [client=(tuner unset), addr=61]
cx25840 2-0044: cx25843-23 found @ 0x88 (ivtv i2c driver #0)
cx25840 2-0044: loaded /lib/modules/HcwMakoA.ROM firmware (14264 bytes)
ivtv0: i2c attach to card #0 ok [client=cx25840, addr=44]
wm8775 2-001b: chip found @ 0x36 (ivtv i2c driver #0)
ivtv0: i2c attach to card #0 ok [client=wm8775, addr=1b]
tda9885/6/7: (ivtv) chip found @ 0x86
ivtv0: i2c attach to card #0 ok [client=tda9887, addr=43]
ivtv0: loading /lib/modules/ivtv-fw-enc.bin
ivtv0: Encoder revision: 0x02050032
ivtv0: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total)
ivtv0: Allocate DMA encoder YUV stream: 161 x 12960 buffers (2048KB total)
ivtv0: Allocate DMA encoder VBI stream: 80 x 26208 buffers (2048KB total)
ivtv0: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total)
ivtv0: Create encoder radio stream
tuner: type set to 38 (Philips PAL/SECAM multi (FM1216ME MK3)) by ivtv i2c driver #0
ivtv0: Initialized WinTV PVR 150, card #0
ivtv: ==================== END INIT IVTV ====================
Alles anzeigen
Moin!
Der Antennenverstärker tut seine Pflicht und das Bild ist jetzt in Ordnung. Hoffentlich bekomme ich dadurch das Flackern seltener...
mini.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!