Neutrino auf der Dreambox

[tmbinc]

Nebenbei ist der hauptsächliche Grund, warum wir bei 2.6.12 stehengeblieben sind, dass a.) die Kernel mit steigender Versionsnummer immer größer und langsamer werden, und b.) es niemand für nötig hält, irgendwelche APIs einigermaßen kompatibel (von "stabil" rede ich ja garnicht) zu halten - bestes beispiel ist devfs, für das es bis heute keine brauchbare alternative gibt (sämtliche auf bash-scripten basierter Müll ist jedenfalls keine).

[seife]

wenn Du dem Kernel bzw. den Treibern beim ioctl Pointer auf structs der neuen API übergibst (was anderes hast Du da mit deinen Versuchen nunmal nicht gemacht).. diese aber nunmal anders aussehen intern.. weil es eben alte API ist.. dann ist das durchaus normal, dass dann der Kernel oopst..

Da stimme ich nicht zu. Typischerweise bekommt man da "-EINVAL".

was soll da anderes bei rauskommen.... da hilft dir auch kein neuer Kernel...

Ein neuer Kernel hätte den Vorteil, daß ich ca. 100 Linux-Kernel Experten an der Hand hätte, die mir beim Fixen meiner Probleme behilflich wären.

Naja und zur Not könnte es auch helfen einfach mal zu fragen.. wenn man irgendwas nicht weiss...

Bis ich den ersten funktionsfähigen Port fertig hatte, war die Antwort auf meine Fragen typischerweise die Gegenfrage "warum nimmst du nicht Enigma" (nein, ich will das Thema hier nicht mehr aufwärmen).

Laß uns das "Kriegsbeil" begraben. Ich werde nicht weiter über den Treiber schimpfen, weil er binonly ist (mögen muß ich ihn ja nicht ;-). Dafür werde ich öfters mal mit technischen Fragen auftauchen.

[seife]

Äehm, was gibt's denn bei der Fernbedienung noch für Schwierigkeiten?
Bei mir funktioniert die problemlos

Die Einstellungen für Wiederholungs- und Anfangsverzögerung sind IMO vertauscht (auch nach meinem gepatche). Allerdings wird die "Wiederholungsverzögerung" (in Wirklichkeit Anfangsverzögerung) überhaupt nicht beachtet. Mein patch fixt das (mit Ausnahme der falschen Beschriftung). Des weiteren passierte es mir, daß die box, wenn ich über einen Kanal wegzappte, der gerade EPG-Probleme hat, nach ein paar Sekunden ein (oder mehrere) Zap-events kamen, da in der RC-Queue noch Tastendrücke waren, die nun "rausfielen".
Oder wenn ich z.B. mit "rot-grün" in die EPG-Übersicht geschaltet habe, was kurz dauert, dann fiel immer noch ein "grün"-Event raus, was dann eine Seite nach oben => ans Ende des Bouquets schaltete.

Manche dieser Sachen habe ich auch schon (weniger drastisch) auf der dbox beobachtet, die Wiederholungseinstellungen waren dort auch immer etwas seltsam. Ich muß mir das auf der dbox auch mal anschauen, da die dboxen aber im praktischen Einsatz sind, kann ich immer nur entweder an der dream (die bisher nicht einsetzbar war) oder an einer dbox basteln ;-)

Mag sein daß das auf der DM500 schlimmer ist, da die keinen richtigen Frontprozessor hat (k.A. ob auf der Dream auch der FP die Fernbedienung behandelt).

Meine "Lösung" ist ebenso drastisch wie häßlich: Nach jedem Tastendruck (noch bevor die Taste abgearbeitet wird), wird so lange aus dem RC-device gelesen, bis dieses "leer" ist. Wenn dabei aber ein key-release event gelesen wird (das ist auch ein Tastendruck, nur mit anderer "Nummer"), dann wird der nicht weggeworfen, sondern abgearbeitet. Ich werde mir das von Ghost vorgeschlagene Umschalten auf /dev/input/event* mal anschauen, um das ordentlich zu lösen, aber bis dahin bringt mein Patch, zumindest auf der dm500, eine wesentlich besser benutzbare Fernbedienung.

Es kann sein, dass die EPG-Probleme auch noch mit der fehlerhaften Zeit (2 Stunden zurück) zusammenhängen.
Dafür habe ich auch etwas gefunden:
In Enigma wird die Zeitzone über die Einträge in /share/zoneinfo/ gesetzt. Die gewählte Zeitzone wird dann in die Datei /var/etc/localtime kopiert.
Da Neutrino keine Einstellungsmöglichkeit für die Zeitzone hat, muss man das also von Hand machen.
Also einfach die entsprechende Datei (für Deutschland ist das "CET") nach /var/etc/localtime kopieren und nach einem Neustart stimmt die Zeit ;)
Die ganzen Vorlagen für die Zeitzonen liegen im CDK in /apps/tuxbox/enigma/data/sysconfig/zoneinfo.tar.bz2

In meinem Patch mache ich das wie auf der dbox, (TZ wird in /etc/profile exportiert) und die Zeit stimmt bei mir auch, daran liegt es also bei mir eher nicht.

[__Ghost__]

Hi,

wenn Du dem Kernel bzw. den Treibern beim ioctl Pointer auf structs der neuen API übergibst (was anderes hast Du da mit deinen Versuchen nunmal nicht gemacht).. diese aber nunmal anders aussehen intern.. weil es eben alte API ist.. dann ist das durchaus normal, dass dann der Kernel oopst..

Da stimme ich nicht zu. Typischerweise bekommt man da "-EINVAL".

Ok.. dahingehend muss ich dann meine Aussage revidieren.. oopsen sollte es wohl wirklich nicht.
Da müsste man dann ggf. mal schauen was da genau oopst, was man dafür tun muss damit es oopst. Aber weiss nicht wirklich ob sich der Zeitaufwand dafür lohnt.

was soll da anderes bei rauskommen.... da hilft dir auch kein neuer Kernel...

Ein neuer Kernel hätte den Vorteil, daß ich ca. 100 Linux-Kernel Experten an der Hand hätte, die mir beim Fixen meiner Probleme behilflich wären.

Naja aber ist eines deiner Probleme denn ein wirkliches Problem des Linux Kernels? Also was auf den Kernel selber zurückzuführen ist?

cu

[seife]

Da müsste man dann ggf. mal schauen was da genau oopst, was man dafür tun muss damit es oopst. Aber weiss nicht wirklich ob sich der Zeitaufwand dafür lohnt. ;)

Eher nicht :-) Es war IIRC einer der DISEQC-ioctls, der die Kiste hart weghing. Zumindest auf der seriellen Konsole war kein oops sichtbar.
Aber ich reproduzier' das jetzt auch nicht :-)

Naja aber ist eines deiner Probleme denn ein wirkliches Problem des Linux Kernels? Also was auf den Kernel selber zurückzuführen ist?

Nachdem ich mich ja so langsam damit abgefunden habe, daß die DM500 für den geplanten Zweck (TV-schauen inklusive aufnehmen auf NFS) nicht einsetzbar ist weiß ich ja noch nicht, wozu ich sie morgen verwenden will (als Türstopper war sie doch zu teuer).

Apropos aufnehmen auf NFS: es wird ja immer so angedeutet (offizielle Aussagen habe ich noch gar keine dazu gesehen), daß die Hardware das nicht kann. Einige "meiner" Experten machen täglich Sachen mit Hardware, die dafür nicht gedacht war, von denen der Hersteller nicht mal geträumt hat. Insofern könnten die schon nützlich sein. Wenn ich denen aber mit einem 3 Jahre alten Kernel und proprietären Treibern komme... nun ja. :-)

[prodigy7]

Hi,

Nachdem ich mich ja so langsam damit abgefunden habe, daß die DM500 für den geplanten Zweck (TV-schauen inklusive aufnehmen auf NFS) nicht einsetzbar ist weiß ich ja noch nicht, wozu ich sie morgen verwenden will (als Türstopper war sie doch zu teuer).

Also ich nutze momentan noch das Russen-Neutrino, entschlackt soweit wie möglich und das Aufnehmen via Aufnahme-Server recorder funktioniert 1a! Kann Sendungen ohne Bildstörungen aufnehmen und ebensogut über die Box von einer NFS-Freigabe abspielen! Das scheint so in der Konstellation auch bei vielen anderen zu funktionieren, was man so im Internet liest.

Apropos aufnehmen auf NFS: es wird ja immer so angedeutet (offizielle Aussagen habe ich noch gar keine dazu gesehen), daß die Hardware das nicht kann. Einige "meiner" Experten machen täglich Sachen mit Hardware, die dafür nicht gedacht war, von denen der Hersteller nicht mal geträumt hat. Insofern könnten die schon nützlich sein. Wenn ich denen aber mit einem 3 Jahre alten Kernel und proprietären Treibern komme... nun ja.

Vielleicht ist ja http://www.dream-multimedia-tv.de/board ... 616&page=2 für dich interessant. Irgendwo (keine Ahnung mehr wo) hat auch mal jemand geschrieben, das er irgendwas debuggt hat und dabei auch festgestellt hat, dass der Netzwerktreiber wohl nicht sauber programmiert sei und das, was er gesehen hätte, ihn auch verstehen lassen würde, warum die Source Closed bleiben würden.

p7

[JtG-Riker]

Vielleicht ist ja http://www.dream-multimedia-tv.de/board ... 616&page=2 für dich interessant. Irgendwo (keine Ahnung mehr wo) hat auch mal jemand geschrieben, das er irgendwas debuggt hat und dabei auch festgestellt hat, dass der Netzwerktreiber wohl nicht sauber programmiert sei und das, was er gesehen hätte, ihn auch verstehen lassen würde, warum die Source Closed bleiben würden.

p7

Das stell ich mal als Unsinn hin, der Netzwerk-Treiber ist doch im Linux-Kernel drin und nicht von dmm, und die dmm-treiber sind closed Source weil das von den Chip-Herstellern so gewünscht ist, das stand auch schonmal irgendwo im dmm-Forum. Kann ich aber auch nachvollziehen sonst würd ja jeder da rumfummeln wer soll sowas noch supporten.

Gruß Riker

[seife]

Das stell ich mal als Unsinn hin, der Netzwerk-Treiber ist doch im Linux-Kernel drin und nicht von dmm

Es reicht, wenn sich der DVB-Treiber ausreichend "danebenbenimmt", so daß er den Netzwerktreiber stört.

und die dmm-treiber sind closed Source weil das von den Chip-Herstellern so gewünscht ist, das stand auch schonmal irgendwo im dmm-Forum.

Das mag sein. Daß IBM in Sachen Linux nicht "die Guten" sind, als die sie sich gern hinstellen, ist schon lange klar, aber...

Kann ich aber auch nachvollziehen sonst würd ja jeder da rumfummeln wer soll sowas noch supporten.

Hm. Interessante Idee. Das werde ich diesen Herren Torvalds, Morton und Kroah-Hartmann (und den anderen) auf der LCE mal erklären, und ihnen vorschlagen, das mit diesem "Open Source"-Zeugs nochmals zu überdenken. Wer soll denn das sonst supporten!

Merkst du was?
Nimm mal an, Dream-Multimedia geht morgen Pleite. Dann sitzen wir hier auf Türstoppern rum.
Hardware ohne offene Treiber ist einfach nur die Hälfte (oder weniger) wert. Ich mache da Dream nicht mal den größten Vorwurf (wobei ich vermute, daß man das hätte eleganter lösen können, mit einem kleinen binärblob für die patentierten MPEG-Dekoder-Routinen. Warum der Treiber für die input devices und die demultiplexer aber closed source sein muß, erschließt sich mir nicht direkt. Schließlich stecken da eher keine "Geheimnisse" drin.

[prodigy7]

Mal ne Frage: Wie rund läuft den das ganze jetzt auf der Dreambox? Wo gibts noch Baustellen? Lässt sich das ganze schon "Produktiv" nutzen?

[jochen_f]

Das stell ich mal als Unsinn hin, der Netzwerk-Treiber ist doch im Linux-Kernel drin und nicht von dmm

Wenn ich das richtig in Erinnerung habe, soll der STBx25xx einen sehr kleinen Hardware-Puffer für den Ethernet Port haben. Wenn also ein anderer Treiber die Interrupts zu lange sperrt, dann führt das definitiv zu Problemen.

und die dmm-treiber sind closed Source weil das von den Chip-Herstellern so gewünscht ist, das stand auch schonmal irgendwo im dmm-Forum.

Das mag sein. Daß IBM in Sachen Linux nicht "die Guten" sind, als die sie sich gern hinstellen, ist schon lange klar, aber...

Ja, offentsichtlich müssen die auch vor Hollywood kuschen.

Allerdings gibt es vielleicht doch Hoffnung:

- der STBx25xx wird auch in anderen Geräten wie dem Hauppauge MediaMVP verbaut.
- es gibt zumindest einen Treiber für den IR Part.
- im Internet findet man einen Treiber für Linux 2.4, der aber offentsichtlich von IBM nicht freigegeben wurde. Mit diesem und dem binären head.ko ließe sich aber eine komplette Dokumentation des Chips erzeugen, mit deren Hilfe dann jemand anderes die restlichen Treiber für 2.6 schreiben kann. Ähnlich ist auch der bcm43xx-Treiber entstanden. Die benötigte Firmware kann z.B. aus dem head.ko (bei DMM) extrahiert werden, darf aber aus bekannten Gründen natürlich nicht weitergegeben werden.

Gruß, Jochen

[seife]

Mal ne Frage: Wie rund läuft den das ganze jetzt auf der Dreambox? Wo gibts noch Baustellen?

Bei mir funktioniert das ganz ordentlich, allerdings laufe ich in das im Neutrino-Forum diskutierte sectionsd-Hänger-Problem regelmäßig rein. (Das Problem existiert wohl auch auf dboxen, aber ich sehe es halt nur auf der dream). Sobald das gefixt ist, stelle ich die dreambox meiner Frau hin, die findet dann die restlichen Bugs.
Eins schneller test letztes Wochenende hat bei mir noch probleme mit dem Movieplayer gezeigt, den hatte ich aber schon früher mal am laufen, das kann also nicht viel sein.

Lässt sich das ganze schon "Produktiv" nutzen?

Das kommt IMO darauf an, ob du in den sectionsd-Bug läufst, oder nicht. Probiers halt mal aus, ich habe bisher praktisch gar kein Feedback bekommen, entweder benutzt es keiner oder es funktioniert perfekt ;-)

[prodigy7]

Das kommt IMO darauf an, ob du in den sectionsd-Bug läufst, oder nicht. Probiers halt mal aus, ich habe bisher praktisch gar kein Feedback bekommen, entweder benutzt es keiner oder es funktioniert perfekt ;-)

Also wenn der sectionsd-Bug weg ist, werde ich mich der Test-Gemeinde anschließen. Das Problem ist, das ich Ärger mit $FRAU bekomme wenn $BOX nicht stabil läuft - kennst das Problem wahrscheinlich auch *g*

[dbluelle]

Mal ne Frage: Wie rund läuft den das ganze jetzt auf der Dreambox? Wo gibts noch Baustellen? Lässt sich das ganze schon "Produktiv" nutzen?

Neben dem leidigen sectionsd Problem ist noch anzumerken, dass der Senderwechsel noch deutlich langsamer als in Enigma ist
(Der Ton ist sofort da, aber das Bild braucht so 1-2 Sekunden).
Ich habe aber noch nicht genauer überprüft, woran das liegt.

dbluelle

[gmo18t]

Eins schneller test letztes Wochenende hat bei mir noch probleme mit dem Movieplayer gezeigt, den hatte ich aber schon früher mal am laufen, das kann also nicht viel sein.

Die Ansteuerung der DVB-Devices ist halt im movieplayer für die DBox "optimiert", d.h. da stecken einige workarounds drin, die für dreambox Hardware bestimmt nicht notwendig sind.
Deshalb würde eine Überarbeitung des Codes allemal nix schaden.

Ich spekulier derzeit damit, mir ne DM600PVR (hab kein Sat, also brauch ich ne C) zuzulegen, dann könnte ich mir den movieplayer vornehmen. Aber die DM600 ist halt "openembedded" ... und wie man da neutrino reinbekommt usw. da steh ich noch ganz dumm da

Ferner steht ja bei den vulcan-Boxen immer noch das "single-demux" Problem im Raum. Da findet man im Inet immer nur schwammige Aussagen zu ...
Bei DMM soll's angeblich demnächst ein neues Image geben, das verbesserte Treiber enthält. Aber solang das nicht restlos geklärt ist, bleibt die Box beim Händler. Denn die Hauptanwendungen die ich nutze, sind "recorder" und "streamer".

Noch ne kurze Frage nebenbei: wo kann ich mehr zum Thema nfs-root (bzw. remote-Boot o.ä.) mit Dreamboxen erfahren ?

- GMo -

[dietmarw]

...Aber die DM600 ist halt "openembedded" ... und wie man da neutrino reinbekommt usw. da steh ich noch ganz dumm da
.

da solltest du dich mal mit audioslyer kurzschließen..

[seife]

Die Ansteuerung der DVB-Devices ist halt im movieplayer für die DBox "optimiert", d.h. da stecken einige workarounds drin, die für dreambox Hardware bestimmt nicht notwendig sind.

Ich hatte den schon auf der dream am Laufen, es kann nicht so wild sein. Entweder habe ich hier einen lokalen Patch, der was kaputtmacht, oder bei dbluelle's Merge ist eine Kleinigkeit kaputtgegangen.

Deshalb würde eine Überarbeitung des Codes allemal nix schaden.

Nicht nur wegen der dream. Movieplayer-Code lesen geht nur vor dem Frühstück, allerdings hat man danach auch keinen Appetit mehr ;-))

Ich spekulier derzeit damit, mir ne DM600PVR (hab kein Sat, also brauch ich ne C) zuzulegen, dann könnte ich mir den movieplayer vornehmen. Aber die DM600 ist halt "openembedded" ... und wie man da neutrino reinbekommt usw. da steh ich noch ganz dumm da :-)

Ferner steht ja bei den vulcan-Boxen immer noch das "single-demux" Problem im Raum. Da findet man im Inet immer nur schwammige Aussagen zu ...
Bei DMM soll's angeblich demnächst ein neues Image geben, das verbesserte Treiber enthält. Aber solang das nicht restlos geklärt ist, bleibt die Box beim Händler. Denn die Hauptanwendungen die ich nutze, sind "recorder" und "streamer".

Allerdings. Ich würde beim derzeitigen Treiberstand auch keinesfalls eine Dreambox kaufen.

Noch ne kurze Frage nebenbei: wo kann ich mehr zum Thema nfs-root (bzw. remote-Boot o.ä.) mit Dreamboxen erfahren ?

Irgendwo gibts da ein Wiki dazu, moment... http://dream.reichholf.net/wiki/Bootlog könnte helfen. Achtung: die kleinen (500 und vermutlich auch 600) haben kein "BIOS", wo man das fest einstellen kann, du mußt es also bei jedem booten neu eingeben. Ich habe typischerweise den Kernel aus dem Flash mit "nfsroot=...." Parametern gebooted. Man könnte aber was vergleichbares wie den "bootmanager" für die usb-boxen auch für "NFS-root" benutzen, also den Kernel aus dem Flash booten, das init-skript setzt zuallererst das netzwerk auf, mounted dein yadd ran und chroot()-ed dann einfach dort rein (je nach Menüauswahl). Das ist zwar nicht perfekt (für Kernel-Experimente taugt's nicht), aber für die meisten devel-Anforderungen sollte das tun.
Ich habe das nur deshalb bisher nicht implementiert, weil ich keine solch grundlegenden Probleme mehr habe. Ich bau einfach den sectionsd neu, kopiere ihn nach /var/bin/ und starte ihn dann von dort ;-)

[seife]

Falscher Alarm; der Movieplayer funktioniert.
Ich weiß nicht woran es lag, aber bis vorhin hat der Movieplayer irgendwie scheinbar immer den mpeg-dekoder zum abschmieren gebracht (kein Signal mehr am FBAS-Ausgang bis reboot). Nun habe ich mal alle Kabel ab- und wieder angesteckt (ich wollte es am TV mit RGB-Eingang probieren, da ich sicher bin, daß es daran schonmal funktionierte) und siehe da: nun geht der Movieplayer einwandfrei. Evtl. war einfach mal ein power-on-reset notwendig :-)

[seife]

Damit funktioniert der Movieplayer sogar noch besser:

Code: Alles auswählen

Index: movieplayer.cpp
===================================================================
RCS file: /cvs/tuxbox/apps/tuxbox/neutrino/src/gui/movieplayer.cpp,v
retrieving revision 1.147
diff -p -u -7 -r1.147 movieplayer.cpp
--- a/movieplayer.cpp   24 Jun 2007 11:51:04 -0000      1.147
+++ b/movieplayer.cpp   15 Jul 2007 19:29:04 -0000
@@ -1827,30 +1827,30 @@ bool TPtrQueue::writerRun(void)
                //-- B2: stop devices here to force restart ! --
                mp_stopDVBDevices(pCtx);
        }

        //-- wait for new segment from queue ! --
        if ( (seg = lockWriteSeg()) == NULL ) return false;

+       //-- B3: may be (re)start of devices --
+       mp_startDVBDevices(pCtx);
        //-- finally transfer segment to dvr device --
        int ofs  = 0;
        int left = SIZE_QUEUE_SEG;
        do
        {
                ofs = write(pCtx->dvr, seg, left);
                seg  += ofs;
                left -= ofs;
        }
        while (left);

        //-- now segment is usable again for reader --
        unlockWriteSeg();

-       //-- B3: may be (re)start of devices --
-       mp_startDVBDevices(pCtx);


        return true;
 }

 void *TPtrQueue::runWrapper(void *p)
 {

Ansonsten wird nämlich auf das device geschrieben, während es noch angehalten ist. Das funktioniert auf der dream nicht. Ich weiß nicht, ob diese Änderung für die dbox auch ok ist, aber ich kann mir nicht vorstellen, daß es was schadet. gmo18t, Kommentare?

[seife]

Neben dem leidigen sectionsd Problem ist noch anzumerken, dass der Senderwechsel noch deutlich langsamer als in Enigma ist
(Der Ton ist sofort da, aber das Bild braucht so 1-2 Sekunden).
Ich habe aber noch nicht genauer überprüft, woran das liegt.

Nicht schön, aber selten. Zum testen reichts erstmal:

Code: Alles auswählen

Index: zapit.cpp
===================================================================
RCS file: /cvs/tuxbox/apps/dvb/zapit/src/zapit.cpp,v
retrieving revision 1.401
diff -u -p -r1.401 zapit.cpp
--- a/zapit.cpp 27 Jun 2007 20:51:04 -0000      1.401
+++ b/zapit.cpp 15 Jul 2007 21:43:47 -0000
@@ -39,6 +39,7 @@
 #include <sys/poll.h>
 #include <sys/socket.h>
 #include <unistd.h>
+#include <sys/ioctl.h>

 #ifdef HAVE_CONFIG_H
 #include <config.h>
@@ -2695,6 +2696,15 @@ int main(int argc, char **argv)
        zapTo(lastchannel.channelNumber);
 #endif

+#define VIDEO_SET_FASTZAP       _IOW('o', 4, int)
+       int mpeg_fd = open("/dev/video", O_WRONLY);
+       if (mpeg_fd > -1) {
+               if (ioctl(mpeg_fd, VIDEO_SET_FASTZAP, 1) < 0)
+                       perror("zapit: VIDEO_SET_FASTZAP");
+               close(mpeg_fd);
+       } else
+               perror("zapit: open /dev/video");
+
        if (update_pmt) {
                while (zapit_server.run(parse_command, CZapitMessages::ACTVERSION, true)) {
                        struct pollfd pfd;

Der Code ist 1:1 aus enigma geklaut. Allerdings muß die Umschaltlogik noch gefixt werden: man kann schon weiterzappen, während der aktuelle Zap-event noch nicht "fertig" ist. Das Weiterzappen wird aber einfach ignoriert :-) Hört sich konfus an, aber probiers einfach mal aus, dann siehst du, was ich meine.

[AudioSlyer]

...Aber die DM600 ist halt "openembedded" ... und wie man da neutrino reinbekommt usw. da steh ich noch ganz dumm da
.

da solltest du dich mal mit audioslyer kurzschließen..

Neutrino hat noch Probleme mit dem Cabletuner, Sat funktioniert aber. Bei schlechterem Wetter schaue ich mir den Kabelpart genauer an.

---edit---
Oh, ich glaub ich hab den Fehler, wird heute Abend getestet

[gmo18t]

...Ich weiß nicht, ob diese Änderung für die dbox auch ok ist, aber ich kann mir nicht vorstellen, daß es was schadet. gmo18t, Kommentare?

also, ih hab bei der DBox so ziemlich alles ausprobiert. Aber es gibt halt immer unzählige Varianten, was wo wann gemacht wird bzw. gemacht werden muß.
Ich denke, ich hab das "Starten" aber bewußt nach dem "Schreiben" gemacht, da das irgendwie besser lief.
Aber ist alles schon sehr lange her

- GMo -

[seife]

Ich denke, ich hab das "Starten" aber bewußt nach dem "Schreiben" gemacht, da das irgendwie besser lief.
Aber ist alles schon sehr lange her

Ok, dann schauts so aus, als ob ich doch mal wieder für die dbox bauen muß, um das selbst zu probieren.
Im Zweifelsfall kann man's ja mit #ifdef HAVE_DREAMBOX_HARDWARE mal so und mal anders machen.

[AudioSlyer]

Yessssssss, auf der DM600pvr-C rennt es nun auch
Zappen ist sehr schnell, ohne Seifes Fix
Die FB ist ein bischl schnell...

[prodigy7]

Mal eine Frage - ein cat /proc/mtd zeigt folgende Ausgabe auf einer

dbox

Code: Alles auswählen

dev:    size   erasesize  name
mtd0: 00020000 00020000 "BR bootloader"
mtd1: 00020000 00020000 "FLFS (U-Boot)"
mtd2: 00660000 00020000 "root (SquashFS)"
mtd3: 00160000 00020000 "var (JFFS2)"
mtd4: 007e0000 00020000 "Flash without bootloader"
mtd5: 00800000 00020000 "Complete Flash"

dreambox

Code: Alles auswählen

dev:    size   erasesize  name
mtd0: 00600000 00020000 "DreamBOX cramfs+squashfs"
mtd1: 001c0000 00020000 "DreamBOX jffs2"
mtd2: 00040000 00020000 "DreamBOX OpenBIOS"
mtd3: 007c0000 00020000 "DreamBOX (w/o bootloader)"
mtd4: 00800000 00020000 "DreamBOX (w/ bootloader)"
mtd5: 004e0000 00020000 "DreamBOX SquashedFS"
mtd6: 00120000 00020000 "DreamBOX Cramfs"

In der Vergangenheit habe ich den aktuellen Stand auf der Dbox gesichert, in dem ich einfach ein cat /proc/mtd/4 > /tmp/mein.img eingegeben habe. Wer ist hier der richtige Kandidat auf der Dreambox? mtd3 sieht gut aus, weis aber nicht, ob ich auf der Dreambox auch so einfach Images sichern und wiederherstellen kann.

prodigy7

[AudioSlyer]

Hier ein Video, leider ewtas dunkel, aber man sieht den Zap-Speed auf der 600er.

http://home.arcor.de/audioslyer/MVI_0800.AVI
Nun rennt aber Neutrino, Enigma und Enigma2 auf meiner Kabelbox
Der Standard-Neutrino-Movieplayer rennt ohne Probleme