neutrinoHD/MP cables/terrestrials positions

[mohousch]

Sorry dass ich diese Frage aus dbox2world hierher migrieren sollte

HI @ll
wenn man den Code vom neutrinoHD/MP anschaut an zwei Stellen:

Code: Alles auswählen

void CServiceManager::WriteSatHeader(FILE * fd, sat_config_t &config)

und denn die Stelle hier:

Code: Alles auswählen

while (search) {
			if (!(strcmp(xmlGetName(search), "sat"))) {
				position = xmlGetSignedNumericAttribute(search, "position", 10);
				char * name = xmlGetAttribute(search, "name");
				InitSatPosition(position, name, false, delsys);
			} else if (!(strcmp(xmlGetName(search), "terrestrial"))) {
				char * name = xmlGetAttribute(search, "name");
				position = fake_pos++;
				position &= 0x0EFF;
				InitSatPosition(position, name, false, delsys);
			} else if(!(strcmp(xmlGetName(search), "cable"))) {
				char * name = xmlGetAttribute(search, "name");
				position = fake_pos++;
				InitSatPosition(position, name, false, delsys);
				satellitePositions[position].cable_nid = xmlGetNumericAttribute(search, "nid", 0);
			}
			ParseSatTransponders(delsys, search, position);
			search = search->xmlNextNode;
		}

in LoadXMLscan oder auch wo anders
denn merkt man dass die position für cables/terrestrial da sinnlos steht obwohl der Wert auch richtig ist, aber man löscht einen cable/terrestrials Provider Eintrag Eintrag aus cables.xml bzw terrestrials.xml denn gibt es channel not found und auch vom reine logik her der position Eintrag was eingentlich ein index aus der cached map ist macht überhaupt kein Sinn.

dennoch eine zweite Frage die seife mit der FuzzyChannels gelöst hat
wozu braucht neutrinoHD/MP in den u/bouquets Einträge die Sat Position?
für die feinen multi service z.B für die Tank ist auch nichts davon ;-)

und genauso die position in der channelid_64
ich sehe überhaupt keinen Nutz für die Position.

noch ein bitte an seife:
ist es possible die existierende terrestrial.xml von enigma2 zu übernehmen statt die magere terrestrial.xml aus den neutrinoMP bzw auch die Einträge Nomination.

[seife]

Ich nutze weder Kabel noch Terrestrisch.
Aber wenn das wer maintainen will, dann sind pull-requests gern gesehen.

Nebenbedingung, damit die akzeptiert werden:

• der Code sollte möglichst in sich abgeschlossen sein, so daß nicht bei jedem merge vom neutrino-hd massive Konflikte auftreten
• rückwärts-inkompatibilität ist ein no-go, ausser es wird sehr gut begründet ("Das hat sowieso noch nie funktioniert" ist z.B. ein gutes Argument ;-))

[mohousch]

nutzen ist eine andere Sache aber zu mindest testen glaube ich terrestrial kannst Du auch testen ;-)

sowas schreibt Neutrino-MP für terrestrial

<TS id="2201" on="2114" frq="746000" inv="2" bw="0" hp="0" lp="0" con="706213824" tm="2" gi="4260500" hi="9950040">

guard_interval, constellation and hierarchy oder ist da irgend eine Konvertierung?

[seife]

Sieht nach uninitialisierten Variablen aus.
Aber wenn ich mich recht erinnere wird das eh alles auf auto gesetzt, ist also wohl egal was da drin steht.

Zum testen müßte ich auf den Dachboden kriechen, und da es offensichtlich niemand braucht ist es den Aufwand nicht wert

[Janus]

Zum testen müßte ich auf den Dachboden kriechen

Geht mir im Moment ähnlich!
Ich hatte mir für den Raspberry eine eigene terrestrical.xml mit den Sendemasten meiner Umgebung erzeugt:
http://www.ueberallfernsehen.de/dvbtdownloads127.pdf

Code: Alles auswählen

<?xml version="1.0" encoding="iso-8859-1"?>
<!-- useable flags are
	1 - Network Scan
	2 - use BAT
	4 - use ONIT
	8 - skip NITs of known networks
	and combinations of this -->

<!-- this file is autogenerated by mk_terrestrial_xml.pl
     WARNING! It is probably unsuitable for enigma! -->
<!-- Parameters are (unfortunately, the neutrino parser does not allow default settings,
     the default is always "0"):
	* bandwidth:
		"0"-8MHz "1"-7MHz "2"-6MHz "3"-AUTO 
	* constellation:
		"0"-QPSK "1"-QAM16 "2"-QAM32 "3"-QAM64 "4"-QAM128 "5"-QAM256 "6"-AUTO 
	* transmission_mode:
		"0"-2k "1"-8k "2"-AUTO 
	* code_rate_[HL]P:
		"0"-NONE "1"-1/2 "2"-2/3 "3"-3/4 "4"-4/5 "5"-5/6 "6"-6/7 "7"-7/8 "8"-8/9 "9"-AUTO 
	* guard_interval:
		"0"-1/32 "1"-1/16 "2"-1/8 "3"-1/4 "4"-AUTO 
	* hierarchy:
		"0"-NONE "1"-1 "2"-2 "3"-4 "4"-AUTO 	-->

<locations>
	<terrestrial name="Colonius" flags="5">
		<transponder frequency="514000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
		<transponder frequency="538000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
		<transponder frequency="594000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
		<transponder frequency="698000" bandwidth="0" constellation="3" transmission_mode="1" code_rate_HP="1" code_rate_LP="1" guard_interval="3" hierarchy="0" />
		<transponder frequency="706000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
		<transponder frequency="730000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
	</terrestrial>
	<terrestrial name="Langenberg" flags="5">
		<transponder frequency="506000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="2" hierarchy="0" />
		<transponder frequency="538000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
		<transponder frequency="586000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
		<transponder frequency="674000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
		<transponder frequency="690000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
		<transponder frequency="722000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
		<transponder frequency="746000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
	</terrestrial>
	<terrestrial name="Duesseldorf" flags="5">
		<transponder frequency="538000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
		<transponder frequency="586000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
		<transponder frequency="674000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
		<transponder frequency="690000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
		<transponder frequency="722000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
		<transponder frequency="746000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
	</terrestrial>
	<terrestrial name="Bonn" flags="5">
		<transponder frequency="514000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
		<transponder frequency="538000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
		<transponder frequency="594000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
		<transponder frequency="698000" bandwidth="0" constellation="3" transmission_mode="1" code_rate_HP="1" code_rate_LP="1" guard_interval="3" hierarchy="0" />
		<transponder frequency="706000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
		<transponder frequency="730000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
	</terrestrial>
	<terrestrial name="Aachen" flags="5">
		<transponder frequency="514000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
		<transponder frequency="602000" bandwidth="0" constellation="3" transmission_mode="1" code_rate_HP="1" code_rate_LP="1" guard_interval="3" hierarchy="0" />
		<transponder frequency="706000" bandwidth="0" constellation="1" transmission_mode="1" code_rate_HP="2" code_rate_LP="2" guard_interval="3" hierarchy="0" />
	</terrestrial>
</locations>

Auch damit blieben einige Attribute auf 'auto'! (die Fehlbelegung der 3 Attribute im TS-Node sind auch bei mir zu sehen)
Und die Verwaltung innerhalb der 'Kanalsuche' und die "Ablage" der Services in der services.xml geschah schlicht über ein Offset und den Counter der terrestrical-Nodes. (Ich habe Signal von zwei Sendemasten)

Was bei anderer "Sortierung" zu fehlerhafter Zuordnung führt. Genau wie bei Kabelboxen, wenn man an der cables.xml rumbastelt.

Da seitens CST für den Tank mal eine Tuner-Zusatzplatine mit der Bestückung C+T1/2 angekündigt war, werden die auch nicht um das Problem korrekter Referenzen herumkommen, wenn neben der 'Integration' von DVB-C (0xF000 + 2Node-Counter in cables.xml" -1) auch noch DVB-T Daten dazukommt. (bei gleichem Schema wäre dann 0xG000 dran , oder? )

Irgendwann muss man diesen Themenkomplex generell mal anfassen. Ein System, das 1999/2000 für Singletuner-Anwendungen (BetaNova-adäquat) geplant und ursprünglich für SD-only und maximal DiSEqC 1.0 konzipiert war, kann man nicht grenzenlos 'aufbohren'. Schon garnicht mit bedingungsloser Rückwärtskompatibilität und Rücksichtnahme auf Uralt-Referenzen in Zusatz-Bausteinen mit Museumscharakter...

Also sollte ein neues, konsistentes Konzept für die Verwaltung der Ressourcen her. Und damit meine ich nicht nur Service-Daten und darauf aufbauendes UI, sondern auch das Managment von Eingangs- und Ausgangsstreams in Anbetracht der verfügbaren Hardware-Austattung. Die letztlich 'eingeführte' frontend.conf war ja schon ein klitzekleiner Schritt in diese Richtung. Aber leider wieder nur auf 'Bewährtes' gesetzt...

[mohousch]

Aber wenn ich mich recht erinnere wird das eh alles auf auto gesetzt, ist also wohl egal was da drin steht.

nein, in anderen Länder nicht.

hat aber keinen Sinn sich selbst einen terrestrial liste zu basteln obwohl die von enigma schon Jahre gibt, naja ist halt neutrino

[seife]

Alle DVB-T-Treiberund alle Chipsatzdatenblätter die ich angeschaut habe machen auto-parameter, deswegen gab es keinen Grund, das im Neutrino ausgiebigst einzubauen, wenn es der Treiber dann doch ignoriert.

Und wozu die terrestrials.xml zig verschiedene Einträge braucht, wenn einer reicht, der einfach alle Kanäle hat (ok, einer Pro ITU-Region) erschließt sich mir auch nicht.

Aber wie gesagt: ich selbst nutze es nicht und Patches schickt ja niemand ;-)

[mohousch]

wärst so nett und schreibst bitte paar zeilen in dem git Wiki wie man baut für die supported platformen, hatte das neutrinomp-pc aus einem clone gebaut und das Resultat ist nicht befriedigend, weiss allerdings nicht ob es überhaupt es das neutrinomp-pc allg. liegt oder an dem aus dem clone ;-)

blicke wirklich nicht mehr hier im Forum oder im tuxbox wiki durch ;-(

[seife]

bitbake neutino-mp

und für PC, gerade nochmal probiert auf openSUSE 13.2

Code: Alles auswählen

cd /dev/shm
mkdir Neutrino-MP-test
cd Neutrino-MP-test
wget https://gitorious.org/neutrino-hd/buildsystem-cs/raw/master:doc/Makefile.native
mkdir source
cd source
git clone git://gitorious.org/neutrino-mp/neutrino-mp.git
git clone git://gitorious.org/neutrino-hd/libstb-hal.git
cd -
make -j 160 -f Makefile.native neutrino

Allerdings habe ich alle dependencies im System installiert, ffmpeg von Packman, alles andere gibts in obs://home:seife:testing

Achso, das "-j 160" sollte man an die eigene Hardware anpassen, ich nehme halt immer zwei mal die anzahl der CPU-Cores / Threads ;-) Und im tmpfs sollte man auch nur bauen, wenn man genug RAM hat.