SDG Radio does not play DAB/DAB+

[jpuigs]

It's finished.

Is there any other way to have a background, different to:

eConsoleAppContainer().execute("showiframe /usr/share/enigma2/radio.mvi")

I ask it, since it needs no less than 25 % cpu , just to see a static image (that is a full hd "video").





Wouldn't it be better to expand skin file utils.py to fullscreen and fullhd and use a .jpg/.png background ?

[athoik]

I didn't know what showiframe causes such load to system.

I guess this one is related only with sf8008?

[jpuigs]

I've checked it with ET 10K, and it does not have such load.
I've checked it with SF 4008, and it doesn't too...
So its a SF8008 Issue....

Wouldn't it be better to expand skin file utils.py to fullscreen and fullhd and use a .jpg/.png background ?

I've done that.
I've converted the radio.mvi file to a 1920x1080 png picture, and I've pasted radiobackground.png file into it.
Then, modificating skin position values (adding 283 h + 225 v) , it fits, and I get the same "Visual" result.
And the cpu load goes downfrom 25% to 2 %...

[jpuigs]

I mean this........





It's easy to do.
In utils.py file , in the skin position values you have to add 283 to horiz. and 225 to vertical, (because the original radiobackground is 1155x630) to get centered on a 1920x1080 picture.
I've done it, then replaced the png file with the new one, and finally disabling mvi reading inside plugin.py... and the result is that cpu load is only 2 %.

The plugin is ready.
Which version do you want ?

The "normal" one, with the radio mvi enabled (as it is now) and original png and utils.py files ? or the modified one ?

[mcelliot_g]

Initially, I designed the graphic ui with a 1920X1080 picture behind it, but we agreed it would be better to have a transparent background for every user to be able to use their own radio.mvi or the background picture that every other image provides (note the plugin is not SDG8 exclusive). Now if we are to go back to that (and this is a collective decision, not one's needs), then certainly a more "neutral" picture will be used again.
This is not a priority though in any means, neither anyone complained about the CPU load, obviously because whatever it is, it does not impact performance.

The priority at this point is to redesign the widgets and add substantial support for DAB info. So, I would suggest to save all GUI stuff for me on a later stage!

[jpuigs]

OK.

I'm waiting to know how athoik wants me to send him the updated py code.
I've modified utils.py too, just to add data for another screen (RAW_DATA), but I haven't modified any of your SKIN_DATA values.

[jpuigs]

[athoik]

Please share the changes here in order to merge stuff that would benefit others too.

Thanks for your efforts!

[jpuigs]

There is a PR on SDGRadio Github
https://github.com/satdreamgr/SDGRadio/pulls

It works fine, there is only one problem that I'm not able to find a solution, and I think it's dab-rtl_tcp-sdgradio-pcm cmdline fault.
I already commented it some days ago, using an RTL_TCP connection, when you change frequency while playing, (preset or manual up/down and OK) plugin kills current cmdline and creates a new one. That's how it works and it can't work in any other way.
The problem is that on RTL_TCP mode, that "killing action" means that the connection to server is closed and server starts to listen again for incoming connections.
But server (at least the rtl_tcp executable found on enigma boxes) isn't very fast waiting for new connections, and then if plugin new cmdline is sent too fast, it gets no response.
We have to stop and restart player (green button).
I've tried to solve it by adding a 3 second delay between stoping and restarting player , that's what happens when you change frequency when is currenty playing,
It seems it works better....
But I faced another problem.... and that's why I think the cmdline is guilty of it....

Look at here... it's a frequency change log using a rtl_tcp server....
That's when it gets connection on new frequency.

dab-sdgradio by SatDreamGr based on dab-cmdline examples
opt = C 11B
opt = W 30
opt = p 68
opt = G 8
opt = H 192.168.0.13
opt = I 1234
server address = 192.168.0.13, port 1234
setting the rate to 2048000
setting the frequency to 218640000
setting the gain to 8
El Mundo Radio   (EFFF) is part of the ensemble
{"ps":"El Mundo Radio  "}
El Mundo Radio   (EFFF) selected as default program
{"programName":"El Mundo Radio  ","programId":"EFFF"}
ensemble MF1              is (EFFE) recognized
There might be a DAB signal here
listener is running
going to start program El Mundo Radio  
protection handler is uep_protection
we have now DAB
    startaddress    = 0
    length        = 116
    subChId        = 5
    protection    = 3
    bitrate        = 160
{"length":"116","bitrate":"160","protectionLevel":"UEP 3","dabType":"DAB","language":" ","programType":"None"}
{"snr":"2","synced":"on","offset":"-8"}
{"snr":"5","synced":"on","offset":"-40"}
MegaStar         (EFF2) is part of the ensemble
{"programName":"MegaStar        ","programId":"EFF2"}
{"snr":"9","synced":"on","offset":"-68"}
{"fic_quality":"76"}
RADIO CLASICA    (EFEF) is part of the ensemble
{"programName":"RADIO CLASICA   ","programId":"EFEF"}
RADIO 1          (EFEE) is part of the ensemble
{"programName":"RADIO 1         ","programId":"EFEE"}
LOS40 CLASSIC    (EFF3) is part of the ensemble
{"programName":"LOS40 CLASSIC   ","programId":"EFF3"}
REE EUROPA       (EFF1) is part of the ensemble
{"programName":"REE EUROPA      ","programId":"EFF1"}
RADIO 3          (EFF0) is part of the ensemble
{"programName":"RADIO 3         ","programId":"EFF0"}
{"snr":"11","synced":"on","offset":"-85"}
{"fic_quality":"100"}
{"snr":"13","synced":"on","offset":"-92"}
{"msc_quality":"100 0 0"}
{"snr":"15","synced":"on","offset":"-95"}
{"snr":"17","synced":"on","offset":"-96"}

The red coloured text IT DOESN'T BELONG to this frequency.
It is something from the previous frequency, and then SDGRadio player tries to play an unknown station.
I've been looking for this on py file, but I don't find anything which produce this mixed content.
When stopping console, DAB, RTL and RAW mode programs list variable which name is self.programs is emptied, ( self.programs = [] ) so It may be cmdline output fault when doesn't receive any data from server.
That issue makes that sometimes, we see one program inside programs list which is not from that DAB MUX, and of course it doesn't play.
Stoping and restarting player (green key) solves it.


And finally, when using RAW file reading, when file reaches its end, player is still mute "playing" because it has no way to know it from cmdline....
When changing program inside MUX recording, I've noticed that the audio is sometimes delayed compared to key orders.

[athoik]

Thank you very much for your contribution.

I really appreciate your help.

Please consider this PR as experintal features.

Some of them will find the way into plugin, others not.

Eg. Translation changes is one commit, and that commit requires changes to translation files, @mcelliot, can you help to create PR?

Another possible commit I see is the fm gain, autogain

Then I see the tcp mode in dab, when enabled it will connect to tcp server. But modulation will be dab, not dab_tcp.

Finally I am still sceptic about raw mode.

It is really experimental change that affects really a lot of code.

For a coder / skinner is great mod, but not for average user.

Please not take above as negative info, it's just my thoughts about plugin improvement vs code maintainability.
I highly support this work as a mod for advance users.