[MarMic]

Hi jungs,

ich fange mal an für die 3.1 zusammeln und niederzuschreiben, was so im forum bereits steht. Bitte sachen anhängen und ich ergänze sie dann im ersten post.

Sachen die bisher fest stehen (oder?):

Code: [Select]

DEVEL:
- ubuntu 12.04
- git

SYSTEM:
- btrfs als root partition
- udev
- überarbeitung remote system (wino)
- neuer paketmanager a la dpkg

SONSTIGES:
-virtuelle tour durch MLD

greetz MarMic

[MarMic]

so meine überlegungen:

NICHT system/devel relevant:
- website umgestalten + webif (habe ne geile idee -> versuche das mal mit PAINT (ja PAINT :-P) umzusetzen, damit du ne vorstellungd avon kriegst, claus.

p.s. hatte noch ne system7devel idee nur bis die 30sec einer neuer nachrichtschreiben verstrichen waren hatte ichs vergessen *fu***

edit// das ist es wieder :-)

system:
- softhddevice als MAIN-forntend nehmen? ich habe da keinen überblick wie stable das mittlerweile ist bzw habe ich nur gelesen dass das alle so toll finden.

greetz MarMic

[clausmuus]

Ja, das softhddevice sollten wir ruhig mal in Betracht ziehen und für nen Testsystem spricht ja auch nichts dagegen. Haupt Vorteil ist, dass das (zumindest gefühlt) viel schneller umschaltet. Hault Nachteil ist wohl die fehlende Medienverwaltung und dass das Teil nicht in der VM läuft. Man sollte mal den Entwickler ansprechen ob's da ne möglichkeit gibt, zumindest das OSD in ner VM zu Gesicht zu bekommen.

Claus

[MarMic]

hmm:

medien:
- da gibt es ja genug alternativen in dem bezug sollten wir vllt nochmal das mpalyerplugin verbessern (erkenung ob dvbff oder x)
- und eben die umschaltung auf XBMC (mein fav :-P)

anzeige in der vm:
- hmm das solltest du machen. ich würde ihm zwar nun im post schreiben, das wir intresse haetten softhddevice in der mld zum standard zu machen, aber die möglichkeit fehlt ind er vm zu testen! problem: ich habe es noch nicht mal einmal gesehen :-) -> kann also nicht mitreden

greetz MarMic

p.s. wegen webiste : spielverderber :-) LOOOL

[wino]

Udev würde ich jedenfalls für sehr gut halten. Nur so ist an die Problematik der FB'en und anderer Hardware zu denken.

Die bisher fehlende Möglichkeit (inputlirc ist ohne udev eine Katastrophe) für die User ihre USB FB zu nutzen, hält diese meiner Meinung nach davon ab, MLD dauerhaft einzusetzen.

MfG
wino

[orgel]

Das Softhddevice in einer VM zum laufen zu bekommen bezweifle ich hier mal. Softhddevive baut auf VDPAU, VAAPI und irgendwann mal XVBA auf, braucht also die entsprechenden Treiber und kann daher gar nicht in einer VM wie VirtualBox oder Qemu laufen. Ich lese mich gerade in die XVBA SDK Dokumentation ein mal sehen ob ich das in Softhddevice einbauen kann  

Gruß
Orgel

[MegaX]

Ja, das softhddevice sollten wir ruhig mal in Betracht ziehen und für nen Testsystem spricht ja auch nichts dagegen. Haupt Vorteil ist, dass das (zumindest gefühlt) viel schneller umschaltet. Hault Nachteil ist wohl die fehlende Medienverwaltung und dass das Teil nicht in der VM läuft. Man sollte mal den Entwickler ansprechen ob's da ne möglichkeit gibt, zumindest das OSD in ner VM zu Gesicht zu bekommen.

Claus

z.Z. läuft SHD nur mit Nvidia(VDPAU) und Intel(VA-API). Die Unterstützung für ATI(XVBA) und VM sollen kommen sobald er es zeitlich schafft. Auch die Einbindung einer Medienverwaltung ist in Planung.

Unter Nvidia läuft das ganze bei mir sehr stabil mit der Version die ich mir über meine Develumgebung selber baue, da die von der Webseite nicht mehr aktuell ist. Das Datum ändert sich zwar sobald es ne neue Version von Johns gibt aber er baut immer die alte Version von anfang/mitte April.

Habe das SHD hier bei mir im Produktivsys seit fast 2 Monaten am laufen.


MegaX

[clausmuus]

Ich hab mich entschieden im Nightbuild wieder die neusten Versionen bauen zu lassen. Es wird also ab Morgen (hoffentlich) wieder das aktuelle softhddevice Plugin geben.

Wieso ist für inputlirc udev erforderlich? Ich hatte bisher noch nichts entsprechendes gehört. Oder besser gesagt, es gab bisher noch keine Beschwerden, das inputlirc nicht funktioniert oder Probleme macht.

Claus

[MarMic]

@claus, ist es nicht aber anscheinend erleichtert es die config?!

 

[wino]

Wieso ist für inputlirc udev erforderlich? Ich hatte bisher noch nichts entsprechendes gehört. Oder besser gesagt, es gab bisher noch keine Beschwerden, das inputlirc nicht funktioniert oder Probleme macht.

Die fehlenden "Beschwerden" bezüglich inputlirc wundern mich allerdings auch. Der Startaufruf verhindert dass inputlirc funktionieren kann. Es müsste inputlircd -d /var/run/lircd -f $INPUTLIRC_ARGS heißen, nicht -d /dev/lircd.

Der Knackpunkt ist die Art der Argumentübergabe. Der Event kann bei jeden Start ein anderer sein. So wie es im Moment gehandhabt wird, wird vdr auch mit der Tastatur von jeder Console aus ungewollt mitgesteuert.

Code: [Select]

register_setting "INPUTLIRC_ARGS" "/dev/input/event* -m 0 -c" "inputlirc Aufruf Argumente"Inputlirc hört nur, ohne Optionsmitgabe auf rc0. Wechselt der Event und somit rc, funktioniert die FB nicht mehr. Mit udev werden solche Probleme ausgeschlossen und eventlircd lässt die Tastencodes ungefiltert durch und somit wird vdr nicht durch Tasteneingaben ungewollt gesteuert.

MfG
wino

[clausmuus]

Nen neuer Paketmanager a la dpkg fehlt noch in Deiner Liste.

Und dann wäre etwas in dieser Art ne feine Sache: http://www.ubuntu.com/tour/en/

Claus

[Matthias]

Nen neuer Paketmanager a la dpkg fehlt noch in Deiner Liste.

Und dann wäre etwas in dieser Art ne feine Sache: http://www.ubuntu.com/tour/en/

Claus

Du meinst eine grafische Einführung/Guided Tour in die MLD?
Ui....
High sophisticated sach ich nur

[clausmuus]

Aber nett ist das
Und ich dachte vor allem an eine Einführung in den VDR

[MarMic]

Wieso ist für inputlirc udev erforderlich? Ich hatte bisher noch nichts entsprechendes gehört. Oder besser gesagt, es gab bisher noch keine Beschwerden, das inputlirc nicht funktioniert oder Probleme macht.

Die fehlenden "Beschwerden" bezüglich inputlirc wundern mich allerdings auch. Der Startaufruf verhindert dass inputlirc funktionieren kann. Es müsste inputlircd -d /var/run/lircd -f $INPUTLIRC_ARGS heißen, nicht -d /dev/lircd.

Der Knackpunkt ist die Art der Argumentübergabe. Der Event kann bei jeden Start ein anderer sein. So wie es im Moment gehandhabt wird, wird vdr auch mit der Tastatur von jeder Console aus ungewollt mitgesteuert.

Code: [Select]

register_setting "INPUTLIRC_ARGS" "/dev/input/event* -m 0 -c" "inputlirc Aufruf Argumente"Inputlirc hört nur, ohne Optionsmitgabe auf rc0. Wechselt der Event und somit rc, funktioniert die FB nicht mehr. Mit udev werden solche Probleme ausgeschlossen und eventlircd lässt die Tastencodes ungefiltert durch und somit wird vdr nicht durch Tasteneingaben ungewollt gesteuert.

MfG
wino

@wino:

hmm das ist so gelöst weil:

es aufjedenfall ein /dev/lircd gibt :-) und er alle abhandeln soll (das ist recht eben wegen fehlendem udev) und was doppelt passiert -> wird eben in der remote.conf auskommentiert

p.s. das war für mich die schnellste und einfachste lösung,d a mir auch die motivation gefehlt hat das richtig zu machen -> ICH Habe solche hardware nicht :-P

deswegen bin ich absolut nicht abgeneigt das so zu lösen das egal was man hat es oob geht!

@claus, das mit dem neuen dpkg habe ich immer noch nicht verstanden!? wieso??? stell mal nen use case auf! (nehme es mal die liste auf)

 

[orgel]

@MarMic, die Abhängigkeiten lassen sich besser auflösen und das Loop Mounting wird eingegrenzt btw. könnte ganz entfallen.