Beiträge von gjung

Hi,

ich bin wieder ein Stück weiter,

der Channel-Scan läuft jetzt so halbwegs, d.h. Section-Filter gehen im Prinzip.

Video/Audio bring viele Fehler, aber immerhin sieht man schon ein Bild,.
d.h. TS-Filter gehen noch nicht, da bin ich noch auf der Suche.

Die Firmware ist echt etwas krank,
z.B. die Art des PID-Filters hängt wohl irgentwie vom gewählten Filter-Index ab:
< 20 ==> Section-Filter
>=20 ==> Video/Audio Filter, die ankommenden Daten sind PES Streams
oder
überall wird mit MSB first gearbeitet, außer beim Datenkopf, da ist LSB first.

Gruß,
Günter

Super, der Mann ist mir echt sympatisch,
oder hast Du da mich nächtens erwischt

Hi,

also die Sache ist eigentlich ganz einfach.
Wenn es mit der aktuellen Firmware keine Möglichkeit gibt zwar gefilterte
TS Packete aber halt immer noch TS Packete zu bekommen, dann ist es nur
mit heftigen Umwegen möglich einen Treiber im dvb Framework zu schreiben.

Also entweder man schreibt einen Treiber ganz an dvb und evtl. auch v4l
vorbei und dann ein Plugin wie ivtv um das mit dem vdr zu verheiraten, oder
(was wohl sehr unwahrscheinlich ist) SCM ermöglicht uns die Firmware umzuschreiben.
D.h. notwendig wäre der aktuelle Firmware-Source und natürlich eine
entsprechende Doku über die verwendeten LSI Logic Chips (da habe ich wie
üblich nur allgemeine Doku, aber keine Register-Level Doku gefunden).

Beide Varianten lohnen sich aber wohl nur, wenn da noch genügend Boxen auf
dem Markt sind, denn das wird sicher eine Angelegenheit von einigen Wochen
bis da was brauchbares rauskommt.

Als erstes sollte man also mal klären ob es vieleicht doch eine Möglichkeit gibt
TS Packete zu erhalten. Das wäre eindeutig die einfachste Variante.

PS.
an alle die mir zwengs Interesse an dem bisherigen Treiberstand geschrieben haben;
ich schick euch den in Kürze (morgen spätestens übermorgen),
ich wollte vorher noch ein bisschen aufräumen.

Gruß,
Günter

Hi,

nach dem was ich jetzt sehe, wird es wohl doch schwierig eine sauberen Treiber zu schreiben.

Das Problem ist hier der PID-Filter der Box, er schickt keine gefilterten TS Packete, sondern
einen bearbeiteten Payload ohne TS Header, das bedeuted zum einen das man das so
ohne weiteres gar nicht in das Demux-Framework der DVB-Treiber unterbringt,
zum anderen muß man die Payloaddaten im Treiber ja nach Filtertyp (PSI, PES) erstmal
interpretieren.

Vieleicht gibt es ja eine Möglichkeit der Firmware zu sagen, sie soll TS Packete schicken,
aber in den SDK Sourcen kann ich sowas nicht finden.

Langer Rede kurzer Sinn, ein Treiber für die Box wird wohl nicht auf die schnelle
möglich sein (außer SCM gibt weitere Informationen preis)

Gruß,
Günter

Hallo,

ich wollte zwischendurch mal ein kurzes Update zu meinen Fortschritten mit der Box posten.

Ich habe zwischenzeitlich einen in dvb-usb eingebundenen Treiber geschrieben der auch schon weitgehend funktioniert.
Ein paar Sachen sind noch nicht ganz so wie sie sein sollten, es gibt da ein paar Widersprüchliche Angaben in den SDK Sourcen, da muß ich noch ein bisschen Debuggen.
Heute Abend komme ich leider nicht mehr dazu, aber ich denke mal dass ich bis morgen Abend eine Version habe die ich dann schon mal verteilen könnte.
Wer Interesse hat kann mir ja mal eine EMail schicken.

Gruß,
Günter

Hab' die Box Dienstag bekommen, aber zu mehr als die mal unter
Windows anzuschließen, einen Firmwareupdate durchzuführen und
zu schauen was geht bin ich nicht gekommen.
Mehr hoffentlich am WE.

Gruß,
Guenter

armageddon

das ging ja ganz schön schnell !!

Danke für die Rückkopplung !

Gruß,
Günter

Hi

ich denke das Problem mit den Audio Spuren und ac3 gelöst zu habe.

in jobs.c methode recording::scan_tracks die Zeile
track = m_audioTracks.insert(m_audioTracks.begin(), data);
in
track = m_audioTracks.insert(m_audioTracks.end(), data);
ändern.

Der Grund ist das mplex die Streams in der Reihenfolge öffnet in der sie
angegeben wurden, aber erst nachdem bei dem vorherigen Stream die ersten
Daten gelesen wurden. Mit dem insert am Anfang der Liste wird die Reihenfolge
der Streams beim Aufruf von mplex rumgedreht. Da die Shell die vdrsync.pl zum
Aufruf von burn-buffers benutzt wird aber erst das Kommando ausführt wenn sie
den StdOutput öffnen kann, und eine FIFO zum Schreiben nur dann geöffnet werden
kann wenn er zum Lesen offen ist, kann vdrsync keine Daten schreiben weil
mplex den Stream noch nnicht offen hat.
Durch das Einketten am Ende der Liste kommt es nicht mehr zu diesem Problem.

Ich hoffe das ist soweit verständlich.

Gruß,
Günter

Hi,

ich habe hier ein PCI-CI und das avboard an einer TT 1.6
In dieser Kombination funktioniert der IR Teil über das avboard nicht mehr und
an diesem CI Modul gibt es leider keinen Jumper für IR mehr.

Da ich das Einschalt-Feature über das avboard nicht verlieren möchte, suche
ich nach einer Lösung, die mir entweder den IR über das CI abschaltet, oder
einen parallel Betrieb mit dem avboard mit nur einem IR Empfänger emöglicht.

Irgentwelche Ideen?

Gruß,
Günter

ich wäre auch dabei
ein mal TT FF 1.6 (S)

Gruß,
Günter

Tja was soll ich sagen, man soll gewisse Dinge einfach nicht ausprobieren wenn man vorher 500Km gefahren und eigentlich etwas müde ist.
Ich hab' zwar gedacht ich hätte den RTC Zugriff beim Shutdown (Rückschreiben der Systemzeit in die RTC) ausgeschaltet, aber das war nicht der Fall.

Der ACPI Wakeup geht auf alle Fälle auch bei mir, so wie es aussieht auch mit Tag. Genau kann ich das aber erst sagen wenn mein Rechner auch heute
abend um 22:35 aufwacht

So jetzt bleiben eigentlich nur noch zwei Kleinigkeiten (Griffin intern anschliessen und Cool&Quiet) und dann bin ich mit dem System erstmal
zufrieden.

Update
ACPI Wakeup geht incl. Tag

Gruß,
Günter

Zitat

Hmm, bei mir hat er für die "Tag-des-Monats"-Adresse (acpi_gbl_FADT->day_alrm) die 13 (dezimal) ermittelt. Habe nur kurze Tests gemacht, aber scheint richtig zu sein!?

bei steht in der FADT auch die 13, wenn das bei Dir geht, dann wundert es mich etwas das es bei mir nicht geht.
Das einzige was ich mir denken kann ist, daß ich einen RTC Zugriff
beim Shutdown übersehen habe. Ich werde mir das heute abend nochmal
anschauen.

Gruß,
Günter

Zitat

Original von berndm
Hallo gjung,
ich hoffe, du hattest eine angenehme vdr-freie Zeit!

Danke, hatte ich

Zitat

Original von berndm
Seltsamerweise behebt der PowerMate mein Reboot-Problem
...
Muss ich das verstehen?

Mehr als seltsam, passt aber zu meinen Erfahrungen mit dem Mainboard.

Zitat

Original von berndm
Ach ja, BIOS Ver. 3.4 sollte man sich wohl besser nicht installieren, weil dort angeblich die Lüfter-/Temperatur-Anpassung rausgefallen ist. Gerade dieses Feature gefällt mir sehr gut. Versteh' einer die Leute bei MSI

Das mit der Lüfter-Anpassung stimmt, man kann die Lüfter Geschwindigkeit
nicht mehr frei wählen. Es sind, wie in anderen BIOSen auch, drei Geschw.
vorgegeben, und man kann nur noch die Temperatur wählen bei denen
diese Drehzahl eingestellt wird.
Aber, diese BIOS Version behebt mein Problem mit der gemischten USB1.0
und USB2.0 Bestückung. D.h. ich habe jetzt keinerlei Re-/Boot Probleme
mehr.
Das einzige was wohl nicht so ohne weiters geht ist der NVRAM Wakeup,
da gibt es Probleme mit der CMOS-Checksum. Ich bin aber nach den
ersten Versuchen zuversichtlich den ACPI Wakeup, incl. Tag-des-Monats,
hinzubekommen. Die Angaben im der FADT Tabelle vom BIOS bzgl.
Tag-des-Monats passen zwar nicht, aber da werde ich ganz frech den
ACPI Treiber hacken.

Gruß,
Günter

Zitat

habe mich auch schon gefragt, was diese Einstellungen zu bedeuten haben

die Reihenfolge der Einträge im BIOS ist falsch. OnChip USB enabled/disabled
USB komplett. EHCI enabled/disabled USB2.0 aber nur wenn OnChip enabled ist.

Zitat

Hattest du das Problem nicht nur, wenn du beides an demselben Steckerblock betreibst?

Das hat sich leider im laufe der Tests auch als zu frühe Freude herausgestellt.
Wie bei vielem anderem auch verhält sich das BIOS nicht immer ganz reproduzierbar.
Es ist in Wirklichkeit wohl so, daß jeglicher gemischt Betrieb zwischen USB1.x und
USB2.0 Geräten zu einem potentiellen Hänger führt. Vieleicht ist das aber auch ein
Powermate Problem, denn laut Protokoll ist Powermate ein USB1.0 Gerät. Leider
habe ich auf die schnelle kein USB1.1 Gerät für einen Gegentest zur Verfügung.

Zitat

Hat es was gebracht?

Leider nicht.

Ich hab jetzt halt mal eine weitere Supportanfrage an MSI gestellt mit der Frage
nach einer neuen BIOS Version, mal schauen was die antworten.

Ansonsten bin ich jetzt erst mal bis Do nächste Woche nicht verfügbar,
ich werde eine bischen Wandern in Südtirol.

Gruß,
Günter

zu früh gefreut. Nach einem Power-Off am Netzteil wird USB mit obiger
Einstellung nicht mehr initialisiert, und der Kernel erkennt gar kein USB
mehr. Das BIOS verhält sich also höchst interresant, wenn USB mal
enabled war, dann bleibt es das auch wenn ich im BIOS disabled einstelle,
egal ob reboot oder shutdown -> standby, erst wenn ich die Power
ganz wegnehme, dann wird der Chipsatz nach den dann gültigen
BIOS Einstellungen initialisiert. Das heist, es gibt keine saubere
Lösung für meine Problem mit der Kombi Griffin + Terratec USB DVB-T.
Denn wenn USB im BIOS enabled ist, dann hängt das BIOS beim USB-Scan
und lässt sich nur durch den Reset-Taster zum weitermachen überreden.

Eine Idee ist mir gerade noch eingefallen, ich schau mal was passiert
wenn ich den Boot via USB Device disable, vieleicht spart sich das
Bios dann ja den USB-Scan.

Gruß,
Günter

Zitat

Original von berndm
Freut mich
Langsam müssten wir alle Probleme durchhaben ...
Bernd

abwarten.

Aber ich habe noch einen Tip bzgl. USB für dich. Ich bin mir nicht ganz
sicher ob diese BIOS Einstellung bei der 3.2 Version auch da ist, da ich
im Zuge meines kleinen Problems auch gleich mal auf 3.3 upgedatet habe.
Bei mir gibt es 2 USB Controller Einstellungen:
1. EHCI Controller
2. OnChip USB-Controller
EHCI habe ich enabled, OnChip USB habe ich disabled, der Kernel
erkennt das OHCI Device trotzdem. Mit dieser Einstellung sind meine
Probleme mit den gemischten 1.0 (Griffin) und 2.0 Geräten weg und
ich kann ohne irgentwelche Spezial-Maßnahmen reproduzierbar
rebooten.

Gruß,
Günter

Ok, mein Board geht wieder!!
Das ziehen der CMOS Batterie für 4h wars, danke Bernd für den Tip.

Gruß,
Günter

Zitat

Original von berndm
Habe irgendwo gelesen, dass die beschriebenen Clear-CMOS-Prozeduren nicht richtig funktionieren, stattdessen solle man die Batterie für 2 Stunden rausnehmen ...

Das werde ich doch mal probieren.

Hatte gestern um 23:15 noch eine Support-Anfrage an MSI (Deutschland!)
geschickt wegen meines Problems.
Um 23:30 hatte ich schon Antwort: ich solle den BIOS Chip zwengs neu
Flashen einschicken.
Heute morgen um 8:00 habe ich zurückgeschrieben daß ich mir nicht
vorstellen kann daß sich das BIOS selbst kaputschreibt.
Um 8:30 hatte ich Antwort: das wohl der Kollege in der Nacht etwas
schnell war und anscheinend doch das Board defekt sei, und ich es
an den Händler zurückschicken soll.
Auch wenn das nicht so direkt hilfreich war, es gibt auch Mainboard-Hersteller
die schnell auf Anfragen von Privatpersonen reagieren.

Gruß,
Günter

Tja was soll ich sagen, nachdem ich innerhalb einer halben Stunde WLAN
zum laufen gebracht habe, bin ich wegen der Reboot Probleme noch mal
ins BIOS um einerseits die Einstellungen mal aufzuschreiben damit ich sie
mit denen von Bernd vergleichen kann und habe dabei andererseits die
Quick-Boot Einstellung aktiviert. Nach dem "Save and Reset" ging nichts
mehr. Ich komme nicht mehr ins BIOS, Clear BIOS und alle anderen
Standard-Maßnahmen fruchten nichts. Es sieht fast so aus alsob die
Quick-Boot Einstellung das Board schlichtweg unbenutzbar gemacht hat.
Das wars dann also erstmal von meiner Seite.

Gruß,
Günter

Zitat

USB-Keyboard u. -Mouse habe ich gleich zu Beginn zusammen mit APIC deaktiviert und nicht weiter beachtet. Trotzdem hatte ich besagte Reboot-Probleme. Welche BIOS-Version benutz du? Habe noch die 3.2, die dabei war.

Interresant, ich benutze auch noch die 3.2 und habe wie gesagt keine
reboot und ACPI Probleme mehr.

Zitat

Bei EHCD gibt es im Kernel noch eine Option mit "Translators" oder so, welches evtl. den "Companion OHCD-Controller" überflüssig machen soll. Vielleicht ist das noch eine Stelle zum Testen?

Da kann man sicher noch mal damit spielen, ich glaube aber nicht das
das die reboot Thematik grundsätzlich löst. Da muß wohl eher MSI
mit einem BIOS Update ran (-> wann auch immer das passieren wird)

Zitat

BTW: Wie hast du den Powermate angeschlossen? Intern über eine USB-Buchse eines gekauften USB-Slotblechs?

Derzeit noch extern, ich muß mir erst noch ein passendes Kabel für
den internen MB Stecker anfertigen.

Zitat

Wie sieht es bei dir mit ACPI-Wakeup und Temperatur-Sensoren aus?

ACPI Wakeup hatte ich nicht geplant. Kurzfristig NVRAM-Wakeup und
lanfristig ein Zusatzboard (AVR + i2c Clock).
Die Temparatursensoren hatte bisher noch gar nicht berücksichtigt,
aber Du hast recht das ist noch eine weitere Baustellen.

Gruß,
Günter