Jump to content

Keywelt 2008 Squashfs Oktober Image V1

SnowHead

Von SnowHead
in Das Keywelt-Image

Empfohlene Beiträge

  • Antworten 322
  • Created
  • Letzte Antwort
GetAway

GetAway

Geschrieben
Geschrieben

@Magixx007

 

Fehlen die oder sehen die nur andersfarbig aus?

 

 

@SnowHead

 

Wäre es möglich das Tool sectionsdcontrol mit ins nächste Image zu nehmen?

Das würde den Umgang mit dem sectionsd eventuell erleichtern.

--restart, --pause, --nopause, --freemem, etc

 

Zu finden unter /apps/tuxbox/neutrino/lib/sectionsdclient

Link zu diesem Kommentar
Auf anderen Seiten teilen
Steevie

Steevie

Geschrieben
Geschrieben

Hallo!

 

Wie auch all die vorigen Images ist auch das Oktober-Release wieder mal einwandfrei - Danke! :D

 

Nur hab ich eine Frage. Was mir aufgefallen ist im Vergleich zum Juni- bzw April-Image, daß

der EPG "länger" zum Laden benötigt... Also wenn ich zB vom ORF auf Premiere schalte

steht "Keine EPG-Informationen" da. Einmal auf die Info-Taste gedrückt, sind die Infos allerdings

sofort aktualisiert! Liegt das eventuell am neuen sectionsd?

Es stört nicht wirklich, mir ist es nur aufgefallen... Die super Umschaltzeiten sind echt der Hammer! :)

 

 

Vielen Dank und liebe Grüße,

Stefan

Link zu diesem Kommentar
Auf anderen Seiten teilen
  • Admin
SnowHead

SnowHead

Geschrieben
  • Autor
  • Admin
Geschrieben

@Magixx007

 

Dieses Verhalten ist mit normaler Vorgehensweise nicht repro-

duzierbar und auch nicht erklärbar. Vom Laden des HDD-Treibers

jedenfalls ist das nicht abhängig eher von irgendwelchen Manipu-

lationen im /var/-Bereich.

 

 

@GetAway

 

Wenn noch Platz bleibt, sehe ich mal zu, daß ich das Teil noch mit

reinkriege, auch wenn es relativ sinnfrei ist.

 

 

@Steevie

 

Dieses Verhalten liegt am sectionsd und ist seife vomTuxbox-Forum,

welcher sich gerade mit dem sectionsd beschäftigt, bekannt.

Link zu diesem Kommentar
Auf anderen Seiten teilen
knorpel22

knorpel22

Geschrieben
Geschrieben

Hallo zusamm :)

 

Ich hab heute mal das neue Image auf meiner Sagem(Kabel) getestet.Ich habe aber das Multicam mit meiner Primacom Karte und camd3 3.868 nicht ans laufen bekommen.Ich habe auch meine alte camd3.config eingearbeitet,es wurde nichts hell.

Wieder zurück zum Keywelt_V1_April_2x_SQUASHFS_2008.img läuft alles wunderbar.

Alles in allem,tolle Arbeit :-)

 

mfg

 

edit:mit einer anderen camd3.config läuft es wieder

Link zu diesem Kommentar
Auf anderen Seiten teilen
SaVita

SaVita

Geschrieben
Geschrieben
@Steevie

 

Dieses Verhalten liegt am sectionsd und ist seife vomTuxbox-Forum,

welcher sich gerade mit dem sectionsd beschäftigt, bekannt.

 

gabs es nicht eine nodebug variante von keywelt user, bei der das zappen zügiger ging? ich finde leider den link nicht mehr.

Link zu diesem Kommentar
Auf anderen Seiten teilen
rhabarber1848

rhabarber1848

Geschrieben
Geschrieben
gabs es nicht eine nodebug variante von keywelt user, bei der das zappen zügiger ging? ich finde leider den link nicht mehr.

Der sectionsd im CVS und Oktober-KW-Image gibt per Default keine Debugmeldungen

mehr auf der seriellen Konsole aus. Diese Ausgabe war für die Verlangsamung

verantwortlich, deshalb sehe ich z.Zt. keinen Sinn für einen sectionsd-nodebug.

In dem von mir genutzten Image läuft der CVS/KW-sectionsd zu meiner vollsten Zufriedenheit.

Link zu diesem Kommentar
Auf anderen Seiten teilen
Conan

Conan

Geschrieben
Geschrieben

hallo erst mal.

Ich hab ein kleines problem beim aufnemen und zwar wird bei der aufname platzt verbraucht aber die datein werden nicht angezeit.

Im tuxcommander werden 2 datein mit dem selben namen angezeigt aber keine der datein hat die endung ts.

Liegt der fehler bei mir oder ist das image schult. Zb. das der datei name zu lang ist und deswegen die endung verschlugt wird.

 

gruss conan

Link zu diesem Kommentar
Auf anderen Seiten teilen
hansie77

hansie77

Geschrieben
Geschrieben
gabs es nicht eine nodebug variante von keywelt user, bei der das zappen zügiger ging? ich finde leider den link nicht mehr.

 

Das mit dem EPG nachladen empfinde ich beim Oktober wesentlich besser als z.B. beim April, wobei das nicht wirklich störend ist. In den meisten Fällen klappt es wie immer, ist nur selten, das kein EPG verfügbar ist im ersten Moment.

Und das scheint wirklich das einzige zu sein, was mir auffiel, alles andere ist bestens gelungen, ich bin voll happy mit dem Image,danke nochmal .

Link zu diesem Kommentar
Auf anderen Seiten teilen
  • Admin
SnowHead

SnowHead

Geschrieben
  • Autor
  • Admin
Geschrieben

@SaVita

 

Das hat nichts mit Debugausgaben zu tun sondern mit der Einschränkung

des ressourcenfressenden Pollings auf neue Daten. Da ist etwas zu viel

wegoptimiert worden.

 

 

@Conan

 

Nimm im SPTS-Modus auf.

 

 

@murphydoe

 

Dieser Feature-Request ist besser im Tuxbox-Forum aufgehoben. Ich

möchte nicht an unnötig vielen Stellen vom CVS abweichen.

 

 

@rhabarber1848

 

Ich denke, dass sie eher schlecht zu komprimieren sind und daher im Squashfs-Teil

des Images genausoviel Platz belegen wie im JFFS-/var-Teil.

Das hat mir nun doch keine Ruhe gelassen und ich habe mal beispielhaft

mit xfs_repair experimentiert und bin zu erstaunlichen Ergebnissen gekom-

men. Ich habe das Root einmal ohne, einmal mit und einmal mit geshrinktem

xfs_repair gebaut. Dabei hat sich herausgestellt, daß die unsgeshrinkte

Binary auf 38% ihrer ursprünglichen Größe komprimiert wird. Die geshrink-

te allerdings nur auf 45% der Größe der ungeshrinkten Version. Das be-

deutet, daß das manchmal praktizierte Shrinken von Binaries im SquashFS-

bereich sogar kontraproduktiv ist (das betrifft jetzt nicht das Strippen, welches

zu einer tatsächlichen Verkleinerung der Files führt).

Im JFFS-Bereich wurde xfs_repair nur auf 47% seiner ursprünglichen Größe

gepackt.

 

SquashFS-Partition mit und ohne xfs_repair

		Filegröße	Partitionsgröße 
geshrinkt	  248243 		6090752
ungeshrinkt	553588		 6049792
ohne			 0			5839350


JFFS2-Partition mit und ohne xfs_repair

		Filegröße	Partitionsgröße 
ungeshrinkt	553588 		1310720
ohne			 0			1048576

Link zu diesem Kommentar
Auf anderen Seiten teilen
cincaid

cincaid

Geschrieben
Geschrieben
@snowhead

kann ich die aufnamen die schon gemacht worden sind retten oder sind die nicht lauffähig?

 

gruss conan

 

Hi,

 

die Aufnahmen einfach mit ProjectX zu einem MPG multiplexen. Vielleicht kennt aber jemand anderes noch ein besseres Programm das sich leichter bedienen lässt.

 

CU

Link zu diesem Kommentar
Auf anderen Seiten teilen
eraser65

eraser65

Geschrieben
Geschrieben
Das hat mir nun doch keine Ruhe gelassen und ich habe mal beispielhaft

mit xfs_repair experimentiert und bin zu erstaunlichen Ergebnissen gekom-

men. Ich habe das Root einmal ohne, einmal mit und einmal mit geshrinktem

xfs_repair gebaut. Dabei hat sich herausgestellt, daß die unsgeshrinkte

Binary auf 38% ihrer ursprünglichen Größe komprimiert wird. Die geshrink-

te allerdings nur auf 45% der Größe der ungeshrinkten Version. Das be-

deutet, daß das manchmal praktizierte Shrinken von Binaries im SquashFS-

bereich sogar kontraproduktiv ist (das betrifft jetzt nicht das Strippen, welches

zu einer tatsächlichen Verkleinerung der Files führt).

Im JFFS-Bereich wurde xfs_repair nur auf 47% seiner ursprünglichen Größe

gepackt.

Da lohnt es sich ja bei einer eventuellen Umsetzung kaum, wegen 7% Gewinn das Shrink-Verfahren im KW-Image mit umzusetzen. wenn dadurch wieder "neue" Instabilitäten oder "Kinderkrankheiten" mit in Kauf genommen werden müssen - von der zusätzlichen Arbeit ganz zu schweigen.

Also, wenn schon dann wohl doch ungeshrinkten Variante.....

 

gruß eraser65

Link zu diesem Kommentar
Auf anderen Seiten teilen
rhabarber1848

rhabarber1848

Geschrieben
Geschrieben

Hi SnowHead,

 

Ich habe heute das erste Mal von shrink gehört, aber ich bin ja auch noch

nicht solange dabei :) Meinst Du dieses Shell-Skript, dass Binaries

mit "gzip -c9" packt und mit einer Entpackroutine in Form eines Shellskripts

versieht? Wenn ja, wundert mich die bessere Kompression in Squashfs nicht,

zumindest nicht, wenn Du --enable-lzma benutzt. Der LZMA-Algorithmus

ist leistungsfähiger als gzip und bzip2. Außerdem ist es für mich nachvollziehbar,

dass mksquashfs mit LZMA-Unterstützung ein ungepacktes xfs_repair besser

komprimieren kann als ein bereits mit gzip gepacktes (geshrinktes) xfs_repair.

 

Dazu kommt, dass beim Ausführen einer geshrinkten Datei diese erst nach

/tmp (also ins RAM) entpackt werden muss. Für mich klingt das Ganze für ein

Squashfs-Image wenig sinnvoll. Interessant wäre es nur, wenn xfs_repair als

optionales Paket nach /var/bin installiert wird. Da es nur selten benötigt wird,

kann der Einsatz von shrink in diesem Fall sinnvoll sein. Auf jeden Fall wird

das Root-Dateisystem 205 KB kleiner, wenn xfs_repair dort nicht enthalten ist.

Wegen der Blockgröße wird das Rootfs sogar 256 KB kleiner, da Du nun eine

rootpartitionsize von 5A0000 anstatt 5E0000 verwenden kannst.

Link zu diesem Kommentar
Auf anderen Seiten teilen
jenser34

jenser34

Geschrieben
Geschrieben

Hallo,

 

hatte mir heute das neue image drauf gezogen, lief alles außer der such lauf via sat. aber das war kein großes prob. hab ide liste per hand eingespielt. was ich festgestellt habe, das der ton sehr übersteuert klang. habe alle einstellungen getestet brachte aber keine zufriedenstellenden ergebnisse. hab jetzt das vorhergehende beta drauf, damit funktioniert es super.

Link zu diesem Kommentar
Auf anderen Seiten teilen
  • Admin
SnowHead

SnowHead

Geschrieben
  • Autor
  • Admin
Geschrieben

@rhabarber1848

 

xfs_repair ist ja von vornherein gar nicht mit drin. Sollte allerdings

irgendwo noch was eingespart werden, werde ich sicher nicht wegen

einer Page eine neue Root-Size verwenden. Ich müßte dann näm-

lich für jede neue Root-Größe extra Tuning-Uboote bauen und sup-

porten. Und daß dann anschließend grundsätzlich ein Uboot für die

falsche Rootsize verwendet und hier über "kein System" gemeckert

werden wird, sagt schon die Erfahrung.

Wie gesagt, im Moment sehe ich keinen zwingenden Grund für das

Verkleinern der Root-Partition.

Link zu diesem Kommentar
Auf anderen Seiten teilen
ex3cut0r

ex3cut0r

Geschrieben
Geschrieben

erstmal ein lob, wie immer ein tolles image! auf anhieb keine probleme!

 

ein kleines habe ich doch, ich weiß aber nicht ob es am neuen image liegt oder ob ich doch etwas anderst eingestellt habe als bisher. mit der suche konnte ich im forum nichts finden, falls es doch ein newbie fehler ist verzeiht mir!

also: ich benutze zur aufnahme den direktaufnahmemodus. das funktioniert auch wie bisher, allerdings wird der fernseher nach beenden der aufnahme schawarz und bleibt das auch bis ich den sender wechsel.

Link zu diesem Kommentar
Auf anderen Seiten teilen
Steevie

Steevie

Geschrieben
Geschrieben
erstmal ein lob, wie immer ein tolles image! auf anhieb keine probleme!

 

ein kleines habe ich doch, ich weiß aber nicht ob es am neuen image liegt oder ob ich doch etwas anderst eingestellt habe als bisher. mit der suche konnte ich im forum nichts finden, falls es doch ein newbie fehler ist verzeiht mir!

also: ich benutze zur aufnahme den direktaufnahmemodus. das funktioniert auch wie bisher, allerdings wird der fernseher nach beenden der aufnahme schawarz und bleibt das auch bis ich den sender wechsel.

 

Probier mal im Menü->Einstellungen->Treiber-/Bootoptionen->AVIA-WatchDog auf EIN stellen!

Bzw falls Du eine Sagem-Box hast, den ENX-WatchDog!

 

 

MfG, Stefan

Link zu diesem Kommentar
Auf anderen Seiten teilen

Archiviert

Dieses Thema ist jetzt archiviert und für weitere Antworten gesperrt.

Gehe zur Themenübersicht

  • Wer ist Online   0 Benutzer

    • Keine registrierten Benutzer online.
×
×
  • Neu erstellen...