Beiträge von MikeDK

ok also .xbmc verzeichnis gelöscht, alle einstellungen neu gemacht, und jetz ist der fehler weg ...

dafür ist mir jetz noch was andres aufgefallen *g*

es gibt keine Einstellung mehr für 'LCD/VFD aktivieren' .... zumindest hätt ich das nicht gefunden
wurde das vielleicht in ein addon ausgelagert?

LCD wär nämlich schon auch wichtig ...

lg, Mike

@C-3PO: habs grad fertig kompiliert und ausprobiert ... vnsi ist drin, und funzt

Dirch: aber das mit deinterlacing speichern funzt bei mir noch immer nicht ... ist genau derselbe käse wie mit pvr-testing2 ... meinst du, es hilft vielleicht was, wenn ich das .xbmc verzeichnis mal lösche?

iNOB: dort steht, dass das in "last minute" broken wurde ... also am 17ten ... das geht aber bei mir schon nicht mehr, seit ich auf die oben genannte svn version umgestiegen bin ... und das ist schon ein paar wochen her

ok super danke!
werd das gleich mal checkouten und versuchen ... hoffentlich rennt das bei mir besser, denn der pvr-testing2 branch ist anscheinend recht buggy ... shoutcast rennt bei mir zum Beispiel auch nicht mehr
(kommt immer Script error Fehlermeldung)

Dirch: danke für die schnelle Antwort! Nur wo gibts diese Version von "Lars" ? (bin nimmer so am laufenden ;))

lg, mike

Moin!

Ich bin hier schon am verzweifeln ... habe folgendes Problem:

Jedes mal, wenn ich auf bestimmte Kanäle schalte, wird Deinterlacing falsch eingestellt.
Also z.B. ich schau grad Pro7, dann will ich auf ORF1HD umschalten. Dort laufen die ersten beiden Sekunden flüssig, danach fängts ganz bitter zum ruckeln an. Dann schau ich in die Video-Settings, und sehe dass das Deinterlacing auf BOB steht. Was natürlich ein Schwachsinn ist, weil ORF1HD 720p ist, und gar kein Deinterlacing notwendig ist!
Wenn ich nun auf nen anderen Kanal schalte, und wieder zurück, ist das wieder genauso falsch.

Ich bin schon kurz vorm Nervenzusammenbruch.
Habs schon mit "TV-Datenbank zurücksetzen" und/oder "Einstellungen als Standard für alle Filme setzen" versucht, kein Erfolg.

Wo zum Geier speichert XBMC diese Einstellung?

Am liebsten wärs mir, wenn standardmässig gar nix deinterlaced wird. Dafür sollte doch im Video-Settings Menü der Punkt "Einstellungen als Standard für alle Filme setzen" da sein, oder?
Aber es funktioniert einfach nicht.

Habe SVN Version 35575 am laufen.

Bilde mir ein, mit ner Version unter 33000 hatte ich diese Probleme nie.

Hilfe ganz dringend erbeten ... WAF hat schon negatives Vorzeichen

LG, Mike

dasselbe problem mit osd rucklern hier bei mir

und zwar nicht nur bei scrollen, sondern auch, wenn ich im menü z.b. nur einmal runter drück ... sobald sich im osd was ändert, ruckelts

besonders nervig ist das bei osdteletext, wenn ich untertitel einschalte ... jedes mal wenn der untertitel sich aktualisiert, gibts nen saftigen ruckler

und nicht nur bei untertitel ... selbst wenn ich auf seite 100 bin, und sich nur die sekunden der zeitanzeige ändern, gibts ruckler ...

wenn ich osd auf 720x576 laufen lasse, gehts flüssig ...

und das problem mit teletext hab ich genauso in xbmc ... kA wie dort der teletext gerendert wird ...
auf hd sendern sind die ruckler hochfrequenter als auf sd sendern (sowohl in xbmc als auch in xineliboutput)

Gruss,
Mike

jo kein problem, bin dir nicht bös hehe

hauptsache es funzt jetz

aber tip: im verzeichnis "contrib" der lirc source gibts init scripte fuer viele distris, unter anderem auch ne datei lirc.debian ... aus dem hab ich dann meins gebaut ...

kann dir ja mal meines posten (hab da noch ein paar sachen dazugepfuscht ... laden/entladen der treiber z.B.... ist jetzt nicht das schönste script, aber es geht *g*) ...:

#! /bin/sh
#
# This is an init script for Debian Sid
# Copy it to /etc/init.d/lirc and type
# > update-rc.d lirc defaults 20
#




test -f /usr/local/sbin/lircd || exit 0


case "$1" in
  start)
    # in case your lirc dev points are not created automatically, the next
    # line will create them.
    # start drivers
    /sbin/modprobe lirc-imon
    /sbin/modprobe lirc-dev
    echo -n "Starting lirc daemon: lircd"
    start-stop-daemon --start --quiet --exec /usr/local/sbin/lircd -- --device=/dev/lirc0
    ln -s /var/run/lirc/lircd /dev/lircd
    echo "."
    ;;
  stop)
    echo -n "Stopping lirc daemon: lircd"
    /sbin/modprobe -r lirc-imon
    /sbin/modprobe -r lirc-dev
    start-stop-daemon --stop --quiet --exec /usr/local/sbin/lircd
    rm /dev/lircd
    echo "."
    ;;
  reload|force-reload)
    start-stop-daemon --stop --quiet --signal 1 --exec /usr/local/sbin/lircd
    ;;
  restart)
    echo -n "Stopping lirc daemon: lircd"
    /sbin/modprobe -r lirc-imon
    /sbin/modprobe -r lirc-dev
    start-stop-daemon --stop --quiet --exec /usr/local/sbin/lircd
    rm /dev/lircd
    sleep 1
    echo -n "Starting lirc daemon: lircd"
    /sbin/modprobe lirc-imon
    /sbin/modprobe lirc-dev
    start-stop-daemon --start --quiet --exec /usr/local/sbin/lircd -- --device=/dev/lirc0
    ln -s /var/run/lirc/lircd /dev/lircd
    echo "."
    ;;
  *)
    echo "Usage: /etc/init.d/lircd {start|stop|reload|restart|force-reload}"
    exit 1
esac


exit 0

ok das heisst, du musst keinen quirk adden ...

welche lirc devices hast du in /dev ?

gibts da ein lirc, lirc0 und/oder lirc1 ?

ich hab da mit meinem 15c2:0038 device nur ein lirc0 ... das heisst, ich muss lirc mit -d /dev/lirc0 parameter starten .. standard maessig nimmt lirc als device aber /dev/lirc

hier noch ein link, wo genau diese problematik beschrieben ist...:

klick

ok zum thema imon hab ich auch noch was parat (auch in ner kiste drin, und vor zwei wochen bei neuinstallation probleme damit gehabt)

mach bitte mal folgende befehle in der konsole

lsusb

und

dmesg | grep HID

letzteren direkt nach dem booten, sonst ist evt. (wie bei mir) der message buffer voll mit vdr meldungen *g*

es könnte sein, dass du die hid quirks setzen musst... sonst holt sich der hid treiber das device, und der lirc treiber kann nicht geladen werden
kommt auf das device an, welches mit lsusb ausgegeben wird ...

dass der mauszeiger sich bewegt, heisst nicht, dass lirc funktioniert...
in manchen dvb treibern ist auch ne remote unterstützung, die funktioniert unabhängig von lirc

wichtig wäre mal zu wissen, welche remote mit welchem empfänger du da jetzt zum laufen kriegen willst

wenn es sich um die tt-connect 3650 mit dem eingebauten empfänger handelt: das ist z.B. ein dvb receiver, dessen dvb treiber auch remote funktionen hat

problem ist (also ich seh das als problem an) dass der dvb treiber maus und keyboard emuliert (über /dev/eventX), was ich aber nicht haben will ... ich will das nur über lirc, drum hab ich das im dvb treiber abgeschaltet, und verwend nen home-made serial empfänger

abschalten kannst du das, wenn du in /etc/modprobe.d eine datei erzeugst (z.B. /etc/modprobe.d/disable_dvb_remote) mit dem inhalt:

options dvb_usb disable_rc_polling=1

damit wird die remote unterstützung der dvb treiber deaktiviert ...

was ich noch nicht geschafft hab ist, den empfänger der tt-connect s2-3650 in lirc zum laufen zu kriegen ... wenn dafuer jemand ne lösung parat hätte, wär ich sehr dankbar ... dann würd ich mir den serial empfänger sparen

Gruss,
Mike

.) hast du vdr mit "make REMOTE=LIRC" kompiliert?

.) existiert /etc/lircd? wenn nicht, dann setz mal nen link:

ln -s /var/run/lirc/lircd /etc/lircd

letzteres hat bei mir geholfen ...
link ist aber nicht notwendig, wenn du vdr mit --lirc=/var/run/lirc/lircd startest ..

Gruss,
Mike

Hoi!

Ich hab ne TT-Connect S2-3600 und ne TT-Connect S2-3650 CI ... beide haben ebenfalls den stb0899 verbaut ... werde das heut oder morgen Abend mal auf beiden Receivern durchlaufen lassen, und dann die logs hier posten...

Gruss,
Mike

newsy: jo sehr seltsam das ganze ... vorgestern, als ich den patch hochgeladen hatte, hab ich noch einige programme überprüft, und der teletext ging auf allen, ausser ard und zdf hd ... (im xbmc)

gestern, als ich auf orf1hd dr. house mit teletext untertiteln schaun wollte, da ging der teletext NICHT ... auf orf2hd ging er, aber auf servustvHD ging er dann seltsamerweise auch nicht ...

und das merkwürdige verhalten, dass man öfter teletext an/aus machen muss, damit zumindest die bunte leiste unten kommt, kapier ich auch nicht ...

konnte gestern dann aber nicht unter vdr-xineliboutput probieren, weil nur noch eine minute bis dr. house war, und wenn wir den versäumt hätten, dann wäre der WAF gefährlich abgesunken *gg*

ich werd heut mal versuchen, meine sat schüssel genauer einzustellen ... denn manchmal hab ich nämlich auch tonaussetzer bei fernsehprogrammen, und manche radio kanäle (z.B. fm4) bekomme ich nur total zerhackt rein

also in meinem patch ist das mit Setup.SupportTeletext nicht mit drin ...
hatte mich heut eh gewundert, wo diese einstellung sein soll ... im vdr menü wäre mir die noch nie aufgefallen ...

könnte es vielleicht sein, dass diese member variable etwas neues ist, das im vanilla vdr nicht drin ist?
also vielleicht ein teil des ttxtsubs patch ...?

gda: hmm das sind aber genau die zwei zeilen, die im ExtP-NG drin sind ... also sharen sich multipatch und extp-ng wohl einige code zeilen (wenn ich das jetz richtig interpretiere)

aelo & löwe: hab dann am nachmittag ein mail mit patch an die vdr mailing liste geschickt ... mal sehn, ob das was wird ...

hatte jetz am abend dann wieder probleme mit teletext ... das hab ich meistens dann, wenn ich ihn grad brauch ... neue dr. house folge, und ich brauch den untertitel für meine liebste, ich freu mich schon, dass ich endlich house in hd schaun kann, und was ist ? teletext geht nicht auf orf1 hd ... auf orf2 hd ging er aber

mah ... schoen langsam glaub ich, ich hab gremlins in meinem vdr case, hehe

so .. hab jetzt den patch gepatched *gg*
hab noch nen check eingebaut, ob ein kanal überhaupt über ne teletext pid verfügt ... nur dann wird diese pid zum cam geschickt ... soll verhindern, dass das cam versucht, die pid 0 (pat table) zu decrypten

den neuen patch gibts in diesem thread

Gruss,
Mike

apropos ... hab noch etwas zum patch hinzugefügt ... es wird jetzt, bevor ein teletext pid ans cam geschickt wird, ein check ausgeführt, ob ein channel überhaupt ne teletext pid hat ... wenn nämlich nicht, dann würde die pid 0 (die pat table) zum cam geschickt werden, und ich glaub das wär nicht so gut *g*

anbei die neue patch version ...

Gruss,
Mike