HDMU_14317_E2_spark7162_217_git_4005_nodebug_mix_U SB

[joeuser]

Installed on nfs server.
Still problem with playing recordings:
playing 1:0:0:0:0:0:0:0:0:0:/hdd/movie/2015082 recording.ts
< 382.851302> [eDVBCAService] free slot 0 demux 0 for service 1:0:1:xxxxxxxxxx:0:0:0:
< 382.852299> [eDVBCAService] free service 1:0:1:xxxxxxxxxxxxxxxxxx:0:0:0:
< 382.906373> [eTSMPEGDecoder] decoder state: play, vpid=ffffffff, apid=ffffffff
< 382.907044> [eDVBPCR0] DEMUX_STOP ok
< 382.907291> [eDVBPCR0] destroy
< 382.907684> [eDVBVideo0] DEMUX_STOP ok
< 382.908743> [eDVBVideo0] VIDEO_STOP ok
< 383.007389> [eDVBVideo0] destroy
< 383.008178> [eDVBAudio0] AUDIO_STOP ok
< 383.103029> [eDVBAudio0] DEMUX_STOP ok
< 383.103723> [eDVBAudio0] AUDIO_CONTINUE ok
< 383.103996> [eDVBAudio0] destroy
cleaning up
TuxTxt cache cleared
< 383.123779> [eDVBResourceManager] start release channel timer
getResolvedKey config.usage.remote_fallback failed !! (Typo??)
< 383.151812> [eDVBServicePMTHandler] alloc PVR
< 383.152548> [eDVBLocalTimerHandler] remove channel 0x2d702808
< 383.153827> [eEPGCache] remove channel 0x2d702808
< 383.166456> [eDVBChannel] getDemux cap=00
< 383.167024> [eDVBResourceManager] allocate demux cap=00
< 383.167471> [eDVBResourceManager] no free demux found
< 383.167719> [eDVBServicePMTHandler] Allocating non--decoding a demux for PVR channel failed.

Restarted just enigma2 three times and remote still works. Again, not sure if something was fixed or I was just lucky...

Pti module problem of tune fail after simultaneous use of tuners still exists.
Replaced pti and stmdvb modules and "tune failed" problem does not occur. But still not possible to playback recordings.

[DboxOldie]

I checked this HDMU Image you posted above:
I can't confirm with your tuner bug > everything is OK without changing any files here !
Description:
I started 2 records with different tuners > switched to another (possible) channnel > OK
I stopped the recordings and checked the tuners > OK
I repeated recording with two tuners > OK
after stopping > tuners were OK.

My sat config: astra only with one cable and 2nd tuner is looped.

The other problem : not playing the fresh recorded records > I confirm that bug.
The records were OK > I tested playing with neutrino > files are playable.

The failure in log is the same : no free demux...and so on

I would search for example here in this changings:


14275 1ecdb1b Athanasios Oikonomou, Tue Nov 10 20:51:16 2015 +0200: eDVBServicePlay: Don't pass m_is_pvr as use_decoding_demux
14274 a2900ae Athanasios Oikonomou, Tue Nov 10 17:56:46 2015 +0200: eDVBResourceManager: fix last commit
14273 38e5606 Athanasios Oikonomou, Tue Nov 10 01:00:44 2015 +0200: eDVBResourceManager: Simplify allocateDemux
....
or:
14282 5910bbe Athanasios Oikonomou, Wed Nov 11 18:27:58 2015 +0200: eDVBResourceManager: allocateDemux, use calculated (fe)source variable
14281 0822762 Taapat, Wed Nov 11 18:39:40 2015 +0200: eDVBServicePMTHandler: remove use_decode_demux from tuneExt, use decode demux only when descrambling


or other patches where demux handling was changed.

[rantanplan]

14258 ist die letzte funktionierende Version.

Edit:
genau auf die Zeilen hatte ich ja auch schon mal vorsichtig hingedeutet.
http://www.hdmedia-universe.com/board/showthread.php?9469-HDMU_14317_E2_ufs913_217_git_4001_nodebug_mix_Flas-h&p=107546&viewfull=1#post107546
Mal sehen, ob das nächste Image klappt.
Die 14137 kann man eigentlich auch wieder löschen.
Stiftet nur Verwirrung, glaube ich.

[DboxOldie]

14258 ist die letzte funktionierende Version.

Das ist bekannt, hilft aber nicht bei der Fehlersuche

Edit:
Würde aber passen, danach ist ja mehrfach an den demuxes gefummelt worden.

[rantanplan]

Ja sag ich ja.
Da hat jemand was verschlimmbessert.
Daher läuft es wahrscheinlich seit 14271 nicht mehr.

Wie gesagt den Auszug hatte ich ja wegen Fehlersuche schon auch angehängt.
Grüße

Edit:
Problem hier scheint auch derzeit zu sein, dass es natürlich alle sh4 Boxen gleichermaßen betrifft.
Von daher sind die logs, die ja dazu auch schon seit der 83er Version bestanden haben ja auch vorhanden. Verlieren sich offensichtlich dann eben auch schnell wieder. Mal steht es bei der ipbox, mal bei der913.
Das log ist immer wieder gleich und deutet eben auf dvb-Service-Fehler hin.
Hab die Versionen alle artig mit getestet und könnte die logs auch noch mal anhängen, aber einmal reicht eigentlich.
Bestätigung gab es ja auch von mehreren Seiten.
Daher der schnelle Hinweis mit 14258.

[DboxOldie]

Ja richtig hatte ich gesehen...
Nur die Tuner Probleme kann ich hier nicht nachvollziehen > das arbeitet.
Hab aber auch an dem Ort wo die Spark steht nur ein Kabel zur Verfügung > daher Loop.

Möglich das bei @joeuser ( aus dem Log vermute ich Drehanlage ? ) die Anlage zu trödelig ist, keine Ahnung ob man irgendwo in den Tuner Einstellungen "tuning retries" einstellen kann wie bei Neutrino.
Da gibt es auch das Problem mit uni-cable oder auch (910) bei CI Betrieb > der Stream kommt zu spät in das demux > pat reading error > zap failed.
Mit Erhöhung dieses Parameters wird der Fehler beseitigt.

[rantanplan]

Ah ok...
ich war ganz bei seinem log und dem Fehler der eigenen Aufnahmen, sorry.

[joeuser]

It is not a problem of the rotor, I can reverse the tuner order and the same thing occurs. I can't post log now, but can later tonight.
I am not sure the problem will occur with a loopthrough connection???
Also, you can try the exact steps I outlined in the other thread.

1. Start stb tuned to FTA channel on tuner C (oscam autostart disabled and not running at all during tests....)
2. Start recording of tuned FTA channel on tuner C
3. Tune FTA channel on tuner B
4. Stop recording
5. Try to tune another FTA channel on tuner B

You can also look at the log I posted in the other thread, it does not have any rotor tuning problems...


Actually, now that I think about it, the problem will not occur with a loop through connection:
From steps above:
1 - you cannot choose which tuner with loopthrough, it will tune the directly connected tuner.
2 - the recording will start ok using same tuner as above.
3 - tuning second channel will force it to use loopthrough tuner.
4 - recording will stop ok.
5 - But now, when you try to tune another channel, it ill use the directly connected tuner and not the loopthrough (which is where the problem is.)

If you start another recording to force it to use second tuner, that also avoids the problem because you can always watch/record from both tuners even after the problem presents itself. (In fact by using third tuner, you can actually rotate the problem to another tuner... but I do not have time now to outline those steps, sorry.)

[DboxOldie]

OK, you choose first Tuner C then B...
I use B the C, because B is the master and C the Loop here.
May other people test with 2 independend sat-cables.

[joeuser]

OK, you choose first Tuner C then B...
I use B the C, because B is the master and C the Loop here.
May other people test with 2 independend sat-cables.

It does not matter which tuner you start with (can even use cable/terrestrial tuner)
Also you do not need to start multiple recordings - you just need one which forces two tuners to be used at the same time.

So, if you have some terrestrial antenna, you can also test...

(Also see the edited post above...)

[rantanplan]

Da mein Englisch in Schrift nix taucht, schreibe ich mal in deutsch weiter...

Kann es ein einfaches Anordnungsproblem sein?
Die Reihenfolge der Tuner unterscheidet sich ja zur Spark-Reihenfolge.
Da gab es auch mal ein Phänomen, welches nur einwandfrei lief bei gleicher Tuner-Anordnung.

Teste mal das alte Open-ARP-Image von Schputnik mit 211er Kernel. Da sind die Tuner genauso angeordnet wie bei Spark.
Um den Fehler eventuell einzugrenzen.

[DboxOldie]

@joeuser:
I have only one sat-cable where the triplex is, so only loop is possible.
But it´s sure that both tuners were use by my tests...
And no loss of tuning when changing to another transponder after record test...

[DboxOldie]

@rantanplan:
Ich weis gar nicht mehr wie die Reihenfolge in Spark ist > seit 3 Jahren nutze ich die Flashbereiche für Test Images.

Ich kenne nur:
fe0 DVB-C/T Tuner 1 Tuner A
fe1 DVB-S Tuner 2 Tuner B
fe2 DVB-S Tuner 3 Tuner C

Das gibt aber der Treiber vor, da die Registrierung am DVB-Adapter so abläuft.

[joeuser]

@joeuser:
I have only one sat-cable where the triplex is, so only loop is possible.
But it´s sure that both tuners were use by my tests...
And no loss of tuning when changing to another transponder after record test...
Thank you for trying, but as I explained above, you will not see the issue with a loopthrough configuration.
(actually, you could test it, but it would involve a bit of hacking. Something like, leave cables connected as they are, disable background scanning, configure second tuner as a different sat than first tuner rather than loopthrough, remove one transponder from main satellite in satellites.xml, remove all channels for that transponder from lamedb, then manually add that transponder to the other sat you have configured for the second tuner. Then, by choosing channels from that transponder you would force it to use the second tuner... But a lot of work and only theoretical :) )


I do not recall which image I used in the past, but I remember once the cable/satellite tuner was tuner C and not A. Maybe Martii's openpli build???

[rantanplan]

OpenAR-P_OE2.0_211_alien2_epl3-git-20-01-14_v2013-03-31-540-gb01d455

Das war seinerseits das Image, wo die TunerBelegung exakt wie bei Spark ist.
Tuner A ->Sat 1
Tuner B ->Sat 2
Tuner C -> DVB T / DVB C

Image halt aus dem alten TDt git.

Damals aufgefallen, da Tuner- Zuordnung mit vielen Images nicht möglich war.
Es wurde anfänglich oft nach Wechsel von Spark auf E2 nur ein "hidden" Tuner angezeigt.
Ich habe jetzt allerdings auch seit ewig nicht mehr in Spark gewühlt.

Das mit der unterschidlichen Tuner-Zuordnung kann man mit dem "SofaSwitch" immer noch gut nachstellen.
(Wenn man mutig ist, HDMU weiß ja das es auch mal zu Ärger führen kann)
Das liegt ja an den DVB-Modulen die geladen bleiben.

Das bringt mich übrigens auf eine andere Idee bzgl Probleme von jouser.....
Vielleicht mal via Tasten komplett wechseln und wieder zurück?

Grüße