Beiträge von leika

Zitat

Original von MacVDR
Hallo,

also ich hab's jetzt mal ausprobiert: Wenn ich einen Timer einstelle, z.B. Heute, 10:05 Uhr und dann den VDR ausmach, wacht er zu diesem Zeitpunkt nicht auf! Also hab ich um 10:05 den Kasten manuell hochgefahren und bin gleich ins BIOS gesprungen. Die Systemzeit stand auf 31.May 2004 / 21:09:xx Uhr.

D.h. bei letzten Runterfahren wurde die Systemuhr durchaus verstellt, nur leider nicht richtig! An was kann denn das plötzlich liegen???

Was mir auch auffällt ist die fehlende Warnung vom VDR, wenn man ausschalten will und sich schon "zu nah" am nächsten Timer befindet. Da wurde man doch immer gefragt, ob man wirklich ausschalten möchte, oder?

Tipp? Ideen?

Alles anzeigen

Ich habe ein ähnliches Problem aber keine Lust zur FEhlersuche. Hat irgendwas mit Zeitzonen zu tun, Settime stellt die Zeit reproduzierbar 2 Stunden zu früh :-))

Mein Workarround besteht darin im Bios die Aufwachzeit nicht auf 23:59 sondern auf 21:59 zu stellen. Ich hab zwar zetzt in der Theorie ein Problem wenn die Aufwachzeit 30 Tage und 23.xx Stunden in der Zukunft liegt aber so lange im Vorraus stelle ich eh keinen Timer ein und lasse überdies den Rechner de vollen 30 Tage ausgeschaltet. Und wenn doch dann ergibt das halt ein zusätzliches aufwachen.

Nicht schön aber tut :-))

Hmm also irgendwie bekomme ich den Eindruck ich müsste mal was positives berichten.

Bei mir lief die Installation ohne Probleme durch, lirc läuft auch sauber. Der Aufwand vom einlegen der CD bis zum ersten Bild (Remote.KBD) betrug ca. 10 min. Bis zum Lirc nochmal 10 minuten mehr.

Netzwerkzugriff war nach Reboot aus war aber mit etwas Linux/Debian Kentnissen leicht wieder herzustellen (ETH0 auf auto setzen).

Danach hab ich noch mal ca. 10 Stunden vor der Kiste verbracht bis er jetzt so ist wie ich haben möchte :

- Plugins installiert
- mpplayer eingerichtet
- X installiert und amarok eingerichtet (Display auf 8Zoll TFT als Partyplayer)
- Kanalliste aufgeräumt
- Skin optimiert
- externe Sammlungen eingebunden (Filme und MP3)

Einige kleine Probleme tauchten natürlich auf so ganz ohne Linux und VDR Vorkentnissen ist diese Distri nicht zu empfehlen. Aber alles in allem nichts dramatisches.

Hallo alle,

eigentlich sollte es doch möglich sein einen reinen Entwicklungs VDR auch ohne DVB Karten aufzusetzten. Ich denke daran auch in längeren Arbeitspausen auf dem Laptop etwas für den VDR zu tun (z.B. Pluginentwicklungen oder GUI Tests) ohne aber eine DVB Karte zu haben.

Hat jemand von euch eine ähnliche Konstellation laufen ? (Streamdev client&Softdevice oder XINE-Plugin???)

mfg stefan

Hi,

wenn du das nicht möchtest dann mußt du das erstellen des Links im vdrconvert unterbinden. Mach einfach mal nen grep "ln -s" vdr2dvd.sh. Es gibt meines wissens nur eine Stelle.

Die Zeile kann man dann per # ausschalten.

mfg Leika

Hi ,

die von dir beschrieben Bugs tauchen bei mir auch auf sind aber IMHO kein Problem des Treibers. Vielmehr hat hier das graphlcd ein Problem die Statuswechsel der Plugins von aussen zu erkennen.

Welche Events werden nicht sauber erkannt ? Wie ich das sehe hängt ein Grossteil der Probleme in der passiven Art des Plugins. So muss z.B. das Plugin beim Parsen der MP3 files auf die Events des Menuesystems reagieren.

Hier bietet sich ein Ansatzpunkt wenn man das ganze umdreht. Wenn man also die Events antriggert.

Hallo alle,

seit zwei Tagen bin ich nun auch stolzer Besitzer eines GraphLCD's. Ich finde dieses Plugin wirklich gut jedoch sind die Wiedergabescreens (speziell die Wiedergabe bei den MP3 Player und DVD) sehr suboptimal.

Nach einigem Nachdenken und stöbern in den Sourcen ist mir auch klar warum. Es ist sehr schwer bis unmöglich an zentraler Stelle (Graphlcd Plugin) eine spezialisierte Ausgabe für alle Plugins und Wiedergaben zu entwickeln.

Im zweiten Schritt kam mir die Idee für eine Lösung. Wie wäre es wenn das GraphPlugin das LCD "exportieren" könnte. Wenn also ein anderes Plugin für eine begrenzte Zeit die Ausgabe auf dem Graphlcd über eine definierte Schnittstelle selbst übernehmen könnte. In diesem Fall könnte dann ein Plugin sehr detaillierte Ausgaben erzeugen und diese evtl. der Displaygröße gemäß anpassen. Wenn also beispielsweise das MP3 Plugin ein Display von 240x128 findet dann sieht man auch die aktuelle Playlist, die ID3Tags sowie die Position des Liedes. Wenn es "nur" ein 128x64 erkennt dann überläßt es dem Graphlcd die Ausgabe da es nicht mehr Platz für zusätzliche Informationen hat.

Was haltet Ihr davon und vor allem ist sowas schonmal begonnen worden ? Wenn nicht dann würde ich meine Ideen am MP3 Plugin und/oder am DVD Plugin mal testen.

mfg Stefan

Ich habs am laufen.

Ich musste den ParPort auf Normal umschalten EPP/ECP funkt nicht.

Hi,

ich habe gerade mein Display von LCD-Aktion bekommen aber ich kann es leider nicht ans laufen bekommen. Ich habe den Parport support fest eingebaut und bin nach der Anleitung hier vorgegangen. Ich habe also die graphlcd Version 0,7 entpackt. den feggy-patch draufgepackt und dann mit
GRAPHLCD_DRIVER=T6963 GRAPHLCD_WIRING=WINDOWS make plugins gebaut

Wenn ich anschliessend vdr mit -P graphlcd starte dann kann ich zwar beobachten das das Display signale bekommt (beim Kanalwechsel) auf dem Display ist aber leider nur Schrott zu sehen.

Unter Windows tut das Teil perfekt. Kann mir vieleicht einer von euch helfen der es am laufen hat ?

Mein ich das nur oder hab ich irgendwo mal ein Script gesehen welches ein blankes skeleton-Plugin Verzeichniss anlegen kann ?????

Hi, es handelt sich um die normale doxygen-Doku die jeder erstellen kann wenn er sich mit doxygen befasst.

Ich hab mir halt gedacht das es u.U. auch ne Menge Entwickler gibt die doxygen noch nicht gesehen haben, sich in den optionen verlaufen haben bzw. nicht alle Zusatzmodule installiert haben :-)))

Es ist (noch) nichts besonderes.

OK,

ich hab gerade ein Pending SF-Project. Wenn das durch ist leg ich die Doku da ab. Wird also nch 2-3 Tage dauern :-))

mfg Stefan

Hi,

ich hab gestern mal ein wenig mit doxygen gearbeitet und eine Dokumentation der VDR-Sourcen erzeugt die einem Entwickler evetl. beim verstehen der Zusammenhänge helfen kann.

Ich könnte diese Doku in drei verschiedenen Formaten anbieten /Falls interesse besteht).

- HTML
- PDF (1 oder 2 Seitig)
- RTF (nicht wirklich zu empfehlen, kam halt auch mit raus :-)) )

Ich selbst arbeite am liebsten mit der html-version.

Sagt mir halt einfach bescheid wenn interesse besteht dann kann ich sie ja irgendwo ablegen (evtl. im Downloadbereich ???)

Hmm ,
das kann schon sein. Ich bin halt hetzt drauf gestossen.

BTW Hat jemand von euch mal Erfahrungen mit der RTELib gesammelt ?

OK, ich habs zwar noch nicht ausprobiert daher .....

aber ein paar Vorschläge hätte ich da schon.

1. MAn könnte die ganzen Shells eliminieren, also die erzeugung des Streams direkt im Plugin lösen und den Xfbv.. in runvdr starten, oder mit nem separaten Startup Script

2. Hast du schonmal daran gedacht das ganze nicht als Plugin sondern z.B. als Device zu implementieren (siehe analogtv). Dann könnten andere Plugins recht einfach darauf zugreifen indem sie auf einen entsprechenden Channel Tunen würden. Ausserdem könnte man vieleicht verschieden Screens unterstützen. Ich könnte dann beispielsweise reine X Programme auf einem bestimmten Screen starten (einfacher Browser, Temp-Control, Newsticker, ....) und dann einfach auf meinen X-Screen umschalten um sie zu sehen.

Mal durchprobieren :-))

Zitat

Original von Doc
Und natürlich

Cheers

Peter

Got me :-))

Hi,

gibt es irgendwo eine gute Doku die den Aufbau des PES beschreibt ?

mfg Stefan

Hi,

ich denke das kann man nicht generell beantworten. die 1.3 ist eine Entwicklerversion und es kann sich grundsätzlich alles ändern :-)). Auch wenn du es jetzt ausprobierst (mit 1.3.2) kann dein Patch schon in der nächsten VErsion übel auf die Nase fallen.

Soviel zur Theorie :-))

Natürlich wird Klaus nicht _ALLES_ neu bauen. Wenn ich seine letzten Beiträge richtig lese und die Mails auf der Liste verfolge werden die geringsten Änderungen wohl im BEreich der Hardcore-Internas geschehen wärend sich die UI sowie das Pluginkonzept u.U. grundlegend ändern wird.

Aber das ist nur eine VErmutung, es kann auch ganz anders kommen

Ok, Vorschlag.

Nur ums klar zu stellen.

Ich wills einfach mal probieren. Ich will ausloten was technisch geht usw. . Mein Ziel ist nicht Java für alles.

Und bitte ich hab schon Performancediskussionen über/mit den verschiedenen Programmiersprachen geführt. Und selbst wenn mein Ziel ein genereller Einsatz von Java wäre dann würde ich diese Diskussion jetzt (noch) nicht führen wollen.

Ich denke folgendes werde ich tun:

1. Ich probier mal aus obs geht.
2. vieleicht schreib ich auch ein oder zwei Plugins. Das der Nutzerkreis potentiell eingeschränkt ist ist dann halt mein Problem.

3. zum Thema PErformance lassen wir die VErmutungen einfach mal sein und schauen uns evtl. die Ergebnisse an.

4. Ich suche einen _unaufdringlichen_ Weg euch auf dem laufenden zu halten.

5. den Thread hier machen wir erstmal zu oder

BTW. Wenn jemand mal ein echtes MHP Plugin schreiben will kommt er an Java eh nicht vorbei :-)))

Schlaft gut, Stefan

Aehmm ich bin nicht vergrämt

Es wäre komisch gewesen wenn ich nicht so eine Reaktion erzeugt hätte und das komische an der Sache ist das in einer PErformancediskussion eigentlich immer jeder irgendwo recht hat

Das hab ich in den letzten 5 Jahren als JAva-Entwickler, Softwarearchitekt und Projektleiter gelernt.

Somit ist jede Meinung erlaubt und damit basta

Aber der Sinn meines Postings ist erfüllt. Es gibt zumindestens Teilweise ein Interesse und ich werde euch zu gegebener Zeit informieren was ich erreicht habe :-))

Bis dahin schau ich nochwas fern.