ma sono iellato....

[SoGo]

vengo al dunque,ho una ss1 ed una airstar2,dopo aver configurato i plugins e mentre mi accingevo a chiudere il tutto mi sono accorto che per prima si avvia la airstar2 quindi non mi consente di vedere i divx(cosi mi sono accorto del danno)....ogni tanto quando gli fa comodo parte la ss1....

come posso risolvere..preciso che ho incrociato e cambiato gli slot....delle stesse.

[ragno]

@SoGo:

soluzione 1): cambi il device primario di vdr (=2). Ricorda che nello script di vdr se e' previsto il load e l'unload dei moduli dopo un restart devi caricare i moduli secondo l'ordine giusto (prima la airstar e poi la ss1)

soluzione 2): disattivi il caricamento automatico dei moduli DVB da parte di udev e carichi i moduli nello script di avvio di vdr secondo le tue esigenze...

ciao

[SoGo]

spero di non fare arrabbiare ninoger ma posto la mail che lui mi ha mandato mi sembra molto utile:

Ciao,
apri il file mplayer.sh.conf e modifica queste 2 righe in questo modo:

VO="mpegpes:card=2"
AO="mpegpes:card=2"

In questo modo i divx torneranno a funzionare fino a quando il sistema non carichera' le schede al contrario.
La seconda soluzione postata da ragno nel forum quella giusta per i nuovi kernel+udev. Solo che bisogna vedere come si fa a dire a udev di non caricare i device delle schede.

Buona giornata.

Nino

ragno anche nino precisa nella mail la tua soluzione e ottimale...ma googlando "udev+vdr"i risultati portano a quello che dici tu....unica pecca non capisco il tedesco,solo in tale lingua si trova qualche procedura x vdr.potresti illuminarci x la seconda soluzione!!!

grazie.

P.S.io ho risolto con quella di ninoger....a me la debian etch carica sempre e solo la dvb-t...quindi va bene anche la soluzione descritta da ninoger nella mail.Ma molto spesso il kernel carica adminki@m i moduli dvb....cioe una volta la ss1 altra volta la ss2.

grazie nino.

[ragno]

@Sogo:
Il tuo problema l'ho avuto anch'io quando sono passato dalla vecchia peanut (kernel 2.6.12) ad archlinux 0.8 con kernel 2.6.20.

Avendo semplicemente migrato gran parte delle configurazioni (script,etc) ho constatato che udev carica prima i moduli della airstar e poi quelli della dvb-s FF.
Al primo caricamento vdr effettuava automaticamente lo switch del device primario, ma poi ne mplayer ne SportClub funzionavano correttamente.

Ho risolto disattivando la funzione di autodetech dell'hardware da parte di archlinux .
Con questa distro devi commentare in /etc/rc.conf MOD_AUTOLOAD, oppure inserire i moduli delle schede dvb in MOD_BLACKLIST per evitarne il caricamento automatico.

Dai un'occhiata alla tua distro se ha un sistema simile per gestire il caricamento dei moduli...

A questo punto dallo script che lancia vdr effettui il caricamento dei moduli secondo le tue esigenze (in pratica io ho lasciato tutto come era con la vecchia distro).

Se hai difficolta' e non riesci a venirne a capo, e non vuoi cambiare tutte le configurazioni con la FF = DVB2 nello script che lancia vdr puoi sempre forzare l'unload dei moduli e ricaricarli secondo l'ordine voluto prima di caricare vdr.

Pero' questo comporta una ulteriore perdita di tempo...

ciao

[von fritz]

Hello
@ragno
anch'io sono emigrato a arch
come ti trovi?

stesso identico problema, a me udev caricava a caso i moduli delle 2 schede DVB (Siemens_full;Nova_budget)
io ho risolto caricando "manualmente" i moduli per la full inserendoli in /etc/rc.conf prima che intervenga udev:

Codice: Seleziona tutto

#
# Scan hardware and load required modules at bootup
MOD_AUTOLOAD="yes"
# Module Blacklist - modules in this list will never be loaded by udev
MOD_BLACKLIST=()
#
# Modules to load at boot-up (in this order)
#   - prefix a module with a ! to blacklist it
#
MODULES=(!8139cp 8139too nvram rtc dvb_core dvb_ttpci)
# Scan for LVM volume groups at startup, required if you use LVM
USELVM="no"

nel mio caso dvb_core e dvb_ttpci, questo naturalmente vale per la mia configurazione e come distro archlinux.

@ragno
come hai velocizzato il cambio canali etc. ?
senza che vada tanto in cerca

bye

[SoGo]

grazie ragazzi...intanto uso la soluzione di ninoger ma intendo smanettare su sta cosa,anche perche' su debian et affini non ce /etc/rc.conf,quindi è meglio comprendere bene sta cosa!!!!!

[ragno]

@von fritz: mi trovo benissimo con archlinx, e' molto simile alla vecchia peanut, ma ha molte cosette in piu'...
Ho installato quasi tutto tramite pacman (binari), le uniche cose che ho compilato (vdr a parte) sono state il kernel (anche eventualmente per utilizzare la versione ottimizzata dei driver dvb FF) e lirc.

Riguardo il caricamento dei moduli, il tuo modo va benissimo, io non volendo stravolgere i vecchi script ho optato per il caricamento manuale da runvdr.

Ecco parte di rc.conf

Codice: Seleziona tutto

# Scan hardware and load required modules at bootup
#MOD_AUTOLOAD="yes"
# Module Blacklist - modules in this list will never be loaded by udev
MOD_BLACKLIST=()
#
# Modules to load at boot-up (in this order)
#   - prefix a module with a ! to blacklist it
#
MODULES=(3c59x lirc_serial !mii) 

Mentre per i servizi allo startup (sempre in rc.conf)

Codice: Seleziona tutto

DAEMONS=(@syslog-ng network @sshd @lircd !xinetd @samba !webmin !netfs !crond)

Ehm, in effetti ho pure installato webmin
Se ne ho bisogno lo attivo da command.conf via telecomando

E alla solita vecchia maniera carico i driver all'interno di runvdr, piu' che altro per poter passare facilmente i parametri ai moduli...(configurazione per dvb-s FF + dvb-t airstar)

Codice: Seleziona tutto

# Load all DVB driver modules needed for your hardware:
function LoadDriver()
{
    modprobe dvb-core dvb_shutdown_timeout=0
    modprobe dvb-ttpci hw_sections=0
    modprobe b2c2-flexcop-pci

}

# Unload all DVB driver modules loaded in LoadDriver():
function UnloadDriver()
{
    modprobe -r dvb-ttpci b2c2-flexcop-pci 

}

Distro naturalmente che gira in solo in modalita' console...Pero c'e' la base per configurazioni meno ortodosse...

Il tempo di zapping (se ti riferisci a quello) e' rimasto lo stesso rispetto alla vecchia peanut (praticamente immediato per quasi tutti i canali)

saluti
ragno

[von fritz]

Hello
@ragno
hw_sections=0
Ahh... ecco cos' era
strano che con la debian non ne ho mai avuto bisogno.
comunque i "movimenti" nei menu mi sembrano ancora un po lentini.... forse e solo un impressione.

bye

[RRT4]

modprobe dvb-core dvb_shutdown_timeout=0
modprobe dvb-ttpci hw_sections=0

cosa fanno le due opzioni di caricamento che ho indicato in grassetto?

mi spiego meglio, io prima facevo caricare i moduli automaticamente dal kernel ed avevo un problema con un plugin (vdr-sysinfo), praticamente una volta su 5 che richiamavo le sysinfo l'OSD si freezava su 'Attendere prego' e dovevo riavviare la vdrbox
ora ho messo i moduli in blacklist e li faccio caricare con le opzioni suindicate tramite /etc/rc.local e il problema sembra sparito

[ragno]

modprobe dvb-core dvb_shutdown_timeout=0
modprobe dvb-ttpci hw_sections=0

Spiegazione maccheronica:

Il primo evita che dopo la chiusura (utilizzo) del frontend (dopo la sintonizzazione di un canale, ad esempio) alla scheda dvb venga tolta l'alimentazione. Spesso questo ha causato problemi a livello di driver, quindi impostando questo parametro a 0 si disattiva questa funzionalita' e i driver funzionano piu' stabilmente.

Il secondo disattiva la possibilita' a livello di firmware di filtrare lo stream TS attivando specifici pids.
A parte una limitazione nel numero massimo di pids gestibili (se non ricordo male per le FF e' di 32), il problema e' che spesso con la modalita' hardware l'AV711x va in crash: per esempio durante la registrazione contemporanea di piu' canali dello stesso trasponder, soprattutto se criptati...

saluti
ragno

P.S. francamente quei parametri sono anni che gli utilizzo e non so se nello sviluppo dei driver le impostazioni di default hanno assunto valori differenti rispetto alle versioni precedenti (imho, credo di no)

[RRT4]

grazie per la spiegazione, come ho detto il problema dell'OSD che freezava con il plugin vdr-sysinfo sembra risolto, maggiore velocità nel cambio canale invece non l'ho notata

per quanto riguarda i crash registrando i canali criptati (anche uno solo alla volta), questi sono sempre avvenuti, in genere dopo 5 minuti di registrazione, ma ho sempre pensato che fossero le ram che avevo settato in cas latency 2 invece di 2,5 e che prevedevo di rimettere a posto non appena avrei ricollegato la vdrbox al monitor in modo da accedere al bios

ora se ho capito bene con hw_sections=0 dovrebbero non presentarsi più, farò delle prove

tnx

[ragno]

@all: per maggiore velocita' dell'osd, provate l'av7110-refactoring driver
http://linuxtv.org/hg/~endriss/v4l-dvb- ... factoring/

ciao