imagebau.GOLDEN MEDIA SPARK

[Tann]

Das Problem fertige Image gibts nur Yaffs von Pinky und Dietmar.W
Selbst wenn Fehler gemeldet werden bei DietmarsImage, in meinen 3 Foren nützt das nix.Changelog gibt es auch nicht, sodass
man nicht weiß welche Fehler sind bekannt, nicht bekannt etc.

[seife]

Mir ging es darum, was das Problem mit den DVB Untertiteln war.

Das pinky-image hat mit meinem Git nicht viel zu tun, und code-sharing ist leider fast unmöglich bzw. extrem anstrengend.

Wenn du hier Fehler im dietmarw-Image meldest, dann wird sich auch drum gekümmert. Soweit ich weiss ist Dietmar's image weitgehend identisch mit dem, was ich mir hier daheim für meine Box baue.

[dietmarw]

bis auf meinen uhr patch ist es original seife git

Code: Alles auswählen

--- infoclock.cpp       2012-05-16 18:34:51.000000000 +0200
+++ infoclock.cpp.neu   2012-06-04 17:00:10.330739972 +0200
@@ -64,11 +64,11 @@
 {
        char timestr[20];
        time_t tm = time(0);
-       strftime((char*) &timestr, sizeof(timestr), "%H:%M:%S", localtime(&tm));
-       timestr[2] = show_dot ? ':':'.';
+       strftime((char*) &timestr, sizeof(timestr), "%H:%M", localtime(&tm));
+       timestr[2] = show_dot ? ':':':';

        int x_diff = (time_width - g_Font[SNeutrinoSettings::FONT_TYPE_INFOBAR_CHANNAME]->getRenderWidth(timestr)) / 2;
-       frameBuffer->paintBoxRel(clock_x, y, time_width, time_height, COL_MENUCONTENT_PLUS_0, RADIUS_SMALL);
+       frameBuffer->paintBackgroundBoxRel(clock_x, y, time_width, time_height);
        g_Font[SNeutrinoSettings::FONT_TYPE_INFOBAR_CHANNAME]->RenderString(clock_x + x_diff, y + digit_h + digit_offset + ((time_height - digit_h) / 2), time_width, timestr, COL_MENUCONTENT);
        frameBuffer->blit();
 }

[martii]

Mir ging es darum, was das Problem mit den DVB Untertiteln war.

Irgendein skandinavischer Sender, der zusätzlich zu den Subtitles (stream id 0xbd) auch einen Padding-Stream mitsendet. Im hohen Norden werden netterweise auch DVB-Subtitles gesendet, die deutlich von den bei uns geläufigen Formaten abweichen (andere Höhe, nicht volle Bildschirmbreite, das Unterscheidungskriterium "48x1280 == HD, Rest == SD" zieht da ggf. nicht mehr. ffmpeg stellt die für Subs verwendete Authoring-Auflösung aber leider nicht über eine ordentliche API zur Verfügung, so dass der Zugriff jetzt zumindest interimsweise über reinkopierte private Header läuft.

Das pinky-image hat mit meinem Git nicht viel zu tun, und code-sharing ist leider fast unmöglich bzw. extrem anstrengend.

Naja. Ich schaff's bisher immer problemlos, Deine Patches zu integrieren. Außerdem hab ich sämtliche Code-Änderungen sowohl in der libstb-hal als auch bei neutrino-hd(-tripledragon) in #ifdef EVOLUX reingepackt und geschaut, dass die Diffs möglichst minimal sind. Das freilich auch aus Eigeninteresse, um Deine Änderungen sauber reinzubekommen.

[Tann]

Marti es wäre schön, wenn es das auch als jffs2 geben würde.

[schufti]

@Tann: ich weiß nicht was ihr jammert. jffs2 Imagebau wird sogar im buildskript von Pinky unterstützt. Es muß sich bloß wer finden, der halt regelmäßig baut, das Image zur Verfügung stellt und sich um online-update kümmert (Funktionalität ist auch im git vorbereitet, bloß geht sie ins Leere, da pinky eben nicht für "Fremdimages" serven will)

aber wie Audio schon mal anmerkte: das ist hier OT.

[pinky1981]

@seife,
es gibt halt noch mehr provider mit subs ausser zdf+ard
bislang is der dvbsub code halt diesbzgl unbenutzbar und das hat martii gefixxed.
obs des übernimmst is natürlich dir überlassen.

[seife]

Um welchen Kanal gehts denn?

Das mit dem Übernehmen ist ja nicht so einfach, "git pull" von euch kann ich nicht machen und manuell das Zeug durchgucken ist mir zuviel Arbeit.

[pinky1981]

c+ oder norskhd kanäle auf thor beispielsweise
des dvb zeugs liegt doch nur im folder /neutrino-hd/lib/libdvbsub
wenns da die paar files nach "ifdef EVOLUX" durchsuchst siehste die anpassungen gleich.

[kentht]

First of all i just wanna say hi from a new user from norway.

Ive been testing dvb subtitle on the gm990 and can concur with pinky that it now work 100%. As we use subtitles on almost all channels in scandinavia, this is a "must" for us to have working correct. When i first tried the Evolux in v. 1.23.0, there were problems with Canal+ hd channels and all NRK channels. The rest of HD channels worked ok. From v.1.24.4 all channels perfect.
Thanx seife pinky and martii for making this possible

[AudioSlyer]

Warum macht ihr nicht einfach ein Diff, wenn ihr es unbedingt drin haben wollt? Ihr nutzt doch sowieso das Pinky-Image. *kopfkratz

[lintux]

Hi @All,
Weiß jemand, wofür das Lua plugin gut ist? lua plugin interface =Skriptsprache ?
Vielen Dank im Voraus

neutrino: add a prototype of a lua plugin interface
this is just for preliminary tests, not yet really usable
for anything useful

[seife]

probiers aus:

Code: Alles auswählen

seife@susi: .../neutrino-mp-x86_64> cat root/lib/tuxbox/plugins/luatest.lua
-- print goes to stdout
print("hallo lua")
RC_home = 174
local n = neutrino() -- max size
sx = SCREEN_OFF_X + 20
sy = SCREEN_OFF_Y + 20
w = SCREEN_END_X - 20 - sx
h = SCREEN_END_Y - 20 - sy
f = FONT_TYPE_CHANNELLIST
n:PaintBox(sx, sy, w, h, COL_MENUCONTENT + 0)
n:RenderString(f, "Hallo Lua!", 100, 100, COL_MENUCONTENT)
msg, data = n:GetInput(1000) -- sleep(1)
n = nil -- funktioniert nicht, ein "destruktor" fehlt noch
sx = SCREEN_OFF_X + 100
sy = SCREEN_OFF_Y + 100
w = SCREEN_END_X - 100 - sx
h = SCREEN_END_Y - 100 - sy
local m = neutrino(sx, sy, w, h);
m:PaintBox(-1, -1, -1, -1, COL_MENUCONTENT + 1) -- max size
m:RenderString(f, "Hallo Lua2!", 100, 100, COL_MENUCONTENT)
repeat
        msg, data = m:GetInput(1000)
        print("msg: " .. msg .. " data: " .. data)
until msg == RC_home
print("ciao!"
--end
seife@susi: .../neutrino-mp-x86_64> cat root/lib/tuxbox/plugins/luatest.cfg
name=Lua Test
desc=tests lua
type=4
needfb=1
needrc=1
needoffsets=1

[lintux]

Hi @Seife,
vielen Dank für deine Antwort . Wenn ich richtig verstanden habe, ersetzt Lua die Msgbox (Messagebox)?
Selber kann ich das leider nicht testen, weil mein alter Laptop den Geist aufgegeben hat. Werde mir im August eine neue Platform holen. (Kinder lassen mich nicht an den Windowslaptop)
Ich übe hier gerade: http://bladehunter.lima-city.de/lua/book/
Thnx.

[martii]

Um das Thema LUA mal ein bisserl aus der Versenkung zu holen:

https://gitorious.org/~martii/neutrino- ... 2de7a29cf5

implementiert Zugriff auf Standard-Neutrino-Menüs. Beispiel (zugegebenermaßen eher sinnfrei, aber als Demo reicht's):

Code: Alles auswählen

local m = menue.new{name="mytitle", icon="myicon", hide_parent=true}
m:addItem{type="back"}
m:addItem{type="separator"}

function talk(a)
	print(">talk")
	print(a)
	print("<talk")
	return MENU_RETURN["RETURN_REPAINT"]
end

function anotherMenue()
	print(">>anothermenue");
	local m = menue.new{name="anothermenue", icon="settings"}
	m:addItem{type="back"}
	m:addItem{type="separator"}
	m:addItem{type="numeric", name="testnumeric"}
	m:exec()
	print("<<anothermenue");
end
				

m:addItem{type="chooser", name="testchooser", action="talk", options={ "on", "off", "auto" }, icon="network", pulldown=1}
m:addItem{type="forwarder", name="testforwarder", action="anotherMenue", icon="network"}
m:addItem{type="separator"}
m:addItem{type="numeric", name="testnumeric", action="talk"}
m:addItem{type="separator"}
m:addItem{type="filebrowser", name="fbrowser", action="talk"}
m:addItem{type="separator"}
m:addItem{type="stringinput", name="stringinput", action="talk"}
m:exec()

Das kann, sofern's keine besseren Implementierungs-Vorschläge gibt (und das kann ich, da ich ein LUA-Noob bin, nicht ausschließen), auch gerne in den Master.

[seife]

Hallo martii,

diese idee hatte ich auch schon, ich habe mich aber dann dazu entschieden, die API die zur skriptsprache hin "entblösst" wird, möglichst klein und einfach zu halten. Der Grund ist ganz einfach:

API-Stabilität.

Je weniger Funktionen in der Lua-API sind, umso seltener muss sie geändert werden und umso länger werden die Skripten ohne Änderung / Anpassung laufen.

Alles was du jetzt an Erweiterungen eigebaut hast, hätte man auch problemlos in Lua selbst implementieren können, ohne verlust an Funktion. Mit dem Vorteil, dass bei Änderungen im Neutrino (und die passieren zur Zeit an diesen Stellen massiv, siee "CComponents") nichts am Skript geändert werden muss. Diese doch sehr spezifischen Menüfunktionen halte ich persönlich für viel zu speziell.

Ich fände es da besser, wenn wir eine Lua-lib mit allgemeinen Funktionen, die man regelmässig braucht mitliefern würden, so dass das nicht in jedem Plugin erneut implementiert werden muss.

Der Grund warum ich da auch momentan nicht viel dran weitergemacht habe ist, dass ich noch warten will, bis die CComponents-Umbauten einigermassen durch sind. Evtl. sollte dann die Lua-API noch mal neu designed werden, so dass die wichtigsten CComponents-Klassen für Lua verfügbar sind, in der Hoffnung dass diese API dann längerfristig stabil bleibt.

Ansonsten würde ich lieber solche Sachen wie A/V-Dekoder und die verschiedenen demuxer zu Lua hin exponieren, damit man z.B. tuxtxt (nich nützlich, den gibt es ja schon) oder hbbtv in Lua implementieren könnte.
Auch zapit-Funktionen (um z.B. im Hintergrund auf dem gerade unbenutzen zweiten, dritten, ... Tuner einen EPG-Scan oder auch einen SAT-Scan zu machen) wären evtl. hilfreich.
Wobei man da darauf achten sollte, dass die API die dann exponiert wird einigermassen generisch, also möglichst nicht zu spezifisch an der Implementation des zapit festgenagelt ist, sonst ändert sie sich wieder alle paar Tage.

[martii]

Hallo seife,

Zugriff auf die Neutrino-Menü-API halte ich für essentiell, damit es zu keinem GUI-Bruch kommt. Eine GUI in LUA nachzuimplementieren wäre zwar denkbar, aber antun wollte ich mir das nicht, und den Widget-Code hatte ich bislang als eher als stabil stabil eingeschätzt -- sofern's da zu größeren Änderungen käme würd's natürlich knallen, aber nicht nur in diesem Kontext.

Mehr als GUI-angepassten Ersatz/Ergänzung für bislang (z.B. via Shellexec) schon ähnlich vornehmbare Erweiterungen kann ich mit den Änderungen freilich nicht vorweisen. Ich bin mir auch nicht sicher, ob das nötig ist -- eine LUA-API für Zugang zu höherwertigen Neutrino-Internas kann leicht aufwendiger werden, als die direkte Neutrino-interne C++-Implementierung des betreffenden Features.

Ciao,

martii