Well..CrossEPG do work excellent on OpenDreambox OE2.0. (thanks DMM).

But since a few days/weeks people experience that the source of XEPGDB from krkadoni.com is offline. (so it's not your enigma2 settopbox, but it's the server of XEPGDB host)

Does anyone know when they restore the "headers_url=" and "descriptors_url= " sources at krkadoni.com?
Or does anyone know another source for XEPGDB electronic program guide data with working "headers_url=" and "descriptors_url= " in the xepgdb.config files?
As alternative we can use rytec of course, but on crossepg XEPGDB is way faster then Rytec.

Here the forum of XEPGDB host: www.krkadoni.com/log/forum/index.php?board=2.0, I try to register their to ask krkadoni for any explanation why XEPGDB is offline, but the website gives a error.

Never knew that EPG import over internet is hosted by just 2 different domains (Rytec and krkadoni). I hope someone else know a working source for ...xepgdb.conf files with working "headers_url=" and "descriptors_url= ".

Here info of the xepgdb sources we can use now, but not available on that server: code.google.com/p/crossepg/source/browse/tags/0.6.2/providers/

Come on you 2 people.
Can you use pm's instead of changing this forum into a Dr. Phil or Oprah board?

Their seems to be an unexpected solution.
What openPli doesn't want to do, is done by OpenATV.
OpenPli base with uptodate oe2.0 drivers from DMM git.
Read here about what OpenATV say .

I found the reason why some picons are not loading.

It seems that OE2.0 *original oe2.0 dreambox image) has no fallback function in how it handles picons. This function is available in OpenPli and OpenVIX.

Here a explanation from ocram picon website (the uptodate picons that i use)
(source )

Zitat

Are you missing picons? Here's why...

There used to be multiple servicerefs like (below is a made up sample):

Channel - Horse and country:
1_0_1_D37C_A2A_2_11A0000_0_0_0
1_0_19_D37C_A2A_2_11A0000_0_0_0
1_0_16_D37C_A2A_2_11A0000_0_0_0

After channel changes:
1_0_1_D37C_A2A_2_11A0000_0_0_0 --> BBC One

These remained unchanged:
1_0_19_D37C_A2A_2_11A0000_0_0_0 --> Horse and country
1_0_16_D37C_A2A_2_11A0000_0_0_0 --> Horse and country

Some time later somebody reports that 1_0_16_D37C_A2A_2_11A0000_0_0_0 is also BBC One.

So we get:
1_0_1_D37C_A2A_2_11A0000_0_0_0 --> BBC One
1_0_19_D37C_A2A_2_11A0000_0_0_0 --> Horse and country
1_0_16_D37C_A2A_2_11A0000_0_0_0 --> BBC One

With 1_0_19_D37C_A2A_2_11A0000_0_0_0 nothing happens and stays in as garbage, because Horse and Country is also changed and has a new serviceref.

So for this 1 example I had to do 2x the same work and we still got 1
obsolete serviceref. After quite some time this builds up and becomes
quite a mess.

So as of now only the unique part is being tracked as tv.D37C_A2A_2_11A0000.uid or radio.D37C_A2A_2_11A0000.uid.

If it's tv. than 1_0_1(=TV) is generated and for XVDR 1_0_1 and 1_0_19, if it's radio. then 1_0_2(=RADIO) is generated.

So why not generate 1_0_19 for Enigma2 also?? Because then I would have to also generate 1_0_16
and many more, users that use the 7z versions for on their USB stick
will complain that the filesize has gone x3, online updates will also
take longer, because there are 3 times as many files.

And since OpenPLI and OpenVIX fallback to 1_0_1 by default if no 1_0_19 or 1_0_16
version is found, problems would be minimal, on my own box I have had
zero issues doing this switchover. Only the Openwebif does not have this
fallback and certain skins that use a different picon renderer. I've
reported this...

If you are experiencing a loss of picons on channels beginning with 1_0_19 or 1_0_16, you are probably using an image not based on OpenPLI.

Alles anzeigen

So please DMM, can you make it possible that our Dreamboxes work properly with those uptodate ocram picons ?
This because these ocram picons are very uptodate( don't know any other picon package that is so frequently updated and multi satellite position).
Do you know other picon packages that supports european satellite positions and most uptodate, and properly working on our Dreambox (no channels without picons that i experience now with ocram picons.

When i click in filezilla (ftp client at computer) on /usr/share/enigma2/picon then i get redirected to /media/cf/picon where the picon files are.

I think it has to do with wrong picon files. I'll check later with other picon files at that cf location.

thanks for feedback.

Zitat von Eberhart

You have to have a skin supporting the picons and/or a proper skin_user.xml, in which the path to your picons is given. So you should check if you have this.

I use this skin for years, always worked. (DMConcinnity-HD-Transp from GeminiPlugin3.2 feed)

I use dreambox-image-dm8000-20131014.nfi.
I have uptodate picons loaded in:
/media/cf/picon
This has always work for years. (really)

But when i press ok button or switch channel, i don't see a picon in the default HD skin (that comes with opendreambox oe2.0). Also no picon when i use other skin.
I did a reflash, but still no picons.

What is wrong, or what do i do wrong?

Yesterday the wors thing what can happen to OpenPli users with Dreamboxes has become reality.

Because of Dream Multimedia their Closed Source action with OE2.0, The OpenPli team quits supporting Dreamboxes.
They (OpenPli) say it's as good as impossible to work on good OpenPli images for Dreamboxes when they cannot look into the source of the closed source part (like drivers when they have a issue).

So the Newest V2 Dreamboxes will never get a OpenPli image, the Older Dreamboxes with OpenPli image, keeps getting updates/new builds until it falls/doesn't work anymore because of change in closed source part.

Here a translation from Dutch to English(by google translate) :

Zitat

OpenPLi stops actively supporting Dream Multimedia STB's

With the decision of Dream Multimedia to abandon open source for their STB's, our motivation for dealing with the consequences of that has dwindled. This has gotten to the point that we are no longer willing to apply Dream Multimedia specific patches, which is why we do not support their v2 STB hardware.

Because current OpenPLi users with Dream Multimedia STB's expect support from us, we feel the need to make our position clear.

We have decided that:

- We will stop fixing Dream Multimedia specific bugs for existing DMM boxes;

- We will not support the "v2" series of Dream Multimedia STB hardware, like the 7020HDv2 and 800SEv2;

- We will not support future Dream Multimedia STB hardware they may release;

The Dream Multimedia hardware currently supported by OpenPLi will remain active in our automated build environment, which means images will be generated and feeds will remain available, until we get to a point that this is no longer possible without intervention. At that point, we will effectively stop with all support.

Since OpenPLi is open source and available to anyone, feel free to setup your own build environment, and produce images for Dream Multimedia hardware yourself, "Based on OpenPLi".

Alles anzeigen

Source link .

My wish is: Dream Multimedia, stop using the new Closed Source license, use the licence at oe2.0 that you also use at oe1.6.

Is your tuner also the LG Hybrid DVB-C / T Tuner CXD 1981 ?

[Blockierte Grafik: http://www.parabola.cz/img_magazin/2011/novinky-dm-hybridni-tuner.jpg]

The DVB-T (sd) is working here, It does support SD and HD at DVB-C, but i'm not sure if it supports DVB-T2.

Wikipedia shows that F2FS is only supported in Linux. (question is, any Linux distro, because if so then i suppose it's gpl'd)

So, in case ofthe topicstarter, if Cable provider sends DVB-C AND DVB-T over coax cable, then don't use one DVB-C/T hybrid tuner.
Use two separate tuners, for DVB-C and DVB-T, and connect them parallel to the coax connection of your cable provider.

MartiniB, sorry for my previous reply, but it sounds so stupid to use DVB-T over Coax. But i guess i'm the one who's stupid.

With update dreambox-image-dm8000-20131001.nfi, same result as above.(box gets slow, freezing moments of tv audio&video, and remultiplex movie proces getting slower and slower.

I updated today 28-9-2013 20:03 , because of this updatemessage : Revert "bdremux: update srcrev and bump PR, fixes freezing on PTS discontinuities at stream start"

Proces is going better. I see the window "Job View" > Remultiplex movie.
It went fine, untill 36/100 , now it seems to be jammed somewhere, DM8000 is having same simptoms: slow responce on buttins, webif andso on.

Hope you continue working on it, because i think everytime it gets a bit better. (better small steps then no step)

why the "[IDLE] 0 600 False" in line 8 ?
Well the bdremux that you posted does it better then the older one that is in the image at the moment, so i'd say, put the version you posted in the feed, maybe we get more feedback of users .

After 5 1/2 hours DM8000 was in standby.
Maybe has to do with the buttons i pressed in the bdremux proces. In BDMV/stream directory on HDD tmp I found more then 1.3GB of data, so bdremux did something (but didn't finish)
I'll try it again, how you describe below, not with movie of more then 90 minutes, but with a small HD recording of MTVN HD, less then 30 minutes. (will speedup remultiplexing

Zitat von Fraxinas

init 5enigma2.sh

I started DM8000, and in telnet i did:
init 5
enigma2

then goto DVD burn plugin, BDMV & burn to medium, select the small MTVN HD recording, it's Remultiplexing now, i keep it in foreground (not pressing blue button to continue in background).
In telnet i get:

[bdremux] added new entrypoint (5497772, 67064306)
[bdremux] added new entrypoint (5498169, 67064306)
[bdremux] added new entrypoint (5498312, 67064306)
[bdremux] added new entrypoint (5498479, 67064306)
nr_read 9598 nr_write 3404
sum 13002 prev_sum 12899
hdd was accessed since previous check!
[IDLE] 0 600 False
It's now  Tue Sep 17 19:38:58 2013
[timer.py] next activation: 1379439638 (in 99920 ms)
It's now  Tue Sep 17 19:38:58 2013
[timer.py] next activation: 1379439638 (in 99898 ms)
nr_read 9598 nr_write 3404
sum 13002 prev_sum 13002
hdd IDLE!
[IDLE] 59.9855861664 600 False
It's now  Tue Sep 17 19:40:38 2013
[timer.py] next activation: 1379439738 (in 99551 ms)
It's now  Tue Sep 17 19:40:38 2013
[timer.py] next activation: 1379439738 (in 99520 ms)
nr_read 9598 nr_write 3404
sum 13002 prev_sum 13002
hdd IDLE!
[IDLE] 120.392949104 600 False
nr_read 9598 nr_write 3404
sum 13002 prev_sum 13002
hdd IDLE!
[IDLE] 180.051192999 600 False
It's now  Tue Sep 17 19:42:18 2013
[timer.py] next activation: 1379439838 (in 99688 ms)
It's now  Tue Sep 17 19:42:18 2013
[timer.py] next activation: 1379439838 (in 99653 ms)
nr_read 9598 nr_write 3404
sum 13002 prev_sum 13002
hdd IDLE!
[IDLE] 239.995102167 600 False
nr_read 9598 nr_write 3404
sum 13002 prev_sum 13002
hdd IDLE!
[IDLE] 300.155021191 600 False
It's now  Tue Sep 17 19:43:58 2013
[timer.py] next activation: 1379439938 (in 99773 ms)
It's now  Tue Sep 17 19:43:58 2013
[timer.py] next activation: 1379439938 (in 99737 ms)
nr_read 9598 nr_write 3404
sum 13002 prev_sum 13002
hdd IDLE!
[IDLE] 360.350613117 600 False
^Cmain thread is non-idle! display spinner!
stopService
[eDVBCAService] free slot 0 demux 3 for service 1:0:1:43A8:2CEC:13E:820000:0:0:0:
[eDVBCAService] free service 1:0:1:43A8:2CEC:13E:820000:0:0:0:
recheckPMTHAndlers()
[TeleText] service stopped
[TeleText] send array('B', [1, 0, 0, 0])
decoder state: play, vpid=-1, apid=-1
DEMUX_STOP - pcr - ok
DEMUX_STOP - video - ok
VIDEO_STOP - failed (Bad file descriptor)
AUDIO_STOP - ok
DEMUX_STOP - audio - ok
AUDIO_CONTINUE - ok
start release channel timer
[HbbTV] disconnecting callbacks
[TeleText] autostart(1, {})
---- saving lame channel db
main thread is non-idle! display spinner!
saved 418 channels and 5846 services!
release cached channel (timer timeout)
[eDVBCAService] remove channel 0x27db260
[eDVBLocalTimeHandler] remove channel 0x27db260
[eEPGCache] remove channel 0x27db260
stop release channel timer
(1) preClose
[EPGC] store epg to realpath '/media/FlashDiskPart1/epg.dat'
[EPGC] 0 events written to /media/FlashDiskPart1/epg.dat
thread joined 0
set RTC to previous valid time
- (41) eHbbtv
- (41) eServiceFactoryBludisc
- (41) eServiceFactoryM2TS
- (41) eServiceFactoryMP3
- (41) eServiceFactoryFS
- (41) eServiceFactoryDVB
- (41) eServiceFactoryDVD
- (40) eServiceCenter
- (35) CI Slots
- (30) eActionMap
- (21) input device driver
- (21) Console RC Driver
- (20) DVB-CI UI
- (20) UHF Modulator
- (20) RC Input layer
- (20) misc options
- (20) HDMI CEC Subsystem
- (20) AVSwitch Driver
- (15) eWindowStyleManager
- (10) gRC
waiting for gRC thread shutdown
gRC thread has finished
- (9) GFBDC
- (9) gLCDDC
- (9) Font Render Class
- (8) graphics acceleration manager
- (5) geminimain
[gMain] Dbus disconnected
[gUtils] save Config /etc/enigma2/gemini_plugin.conf
[gMain] stopped
thread joined 0
- (1) Background File Eraser
eBackgroundFileEraser got quit message
thread joined 0
reached rl -1

Before the first line with [bdremux] added new entrypoint (5497772, 67064306) it all went fine.

Hope you can see what's happening, because i have no idea why the plugin quits. & no audio, screen black and display black.
I did a reboot in telnetsession to get DM8000 back.
After reboot i see that the plugin did something, because in:
/media/hdd/movie/tmp/bludisc_201309171923/BDMV/STREAM
the 00000.m2ts file is 947.2 MB

Zitat von Fraxinas

it turns out that there is a timestamp discontinuity at the beginning of your sample file. since this is probably a common situation, i've added a workaround to make the bdremux process more robust.
would you like to try it the updated version and give me feedback whether it works for you in this and other cases?
please copy over the archive to your box and decompress using the telnet command

Code

tar -xvzf bdremux.tgz -C /usr/bin/

(or decompress on your PC and overwrite the /usr/bin/bdremux file on your box)

you don't need to restart your box or enigma2, just re-run the bdmv burning plugin again and see what happens
thanks for reporting this issue!

Alles anzeigen

Timestamp discontinuity sounds logical, because after a recording most users remove the stuff before the movie and after the movie. (or in a recording advertisement blocks).

I'm at work now, when i'm at home i'll give it a try, thanks for the fast reply
Update1: went home, just to overwrite bdremux, and start bdmv burning on BD-RW disc. I select continue in background and exit dvdburn plugin. DM8000 cannot set to standby. So i suppose bdremux continue working.
I continue my work and see later when i get home what happened.(how process continues and burn to bluray disc)

Update2: Issue that i have now is. I cannot see tv.
DVI-D output (hdmi) on DM8000 is only working if device on other side of cable(hdmi) is switch on first, and then dm8000. (this is since the beginning of oe2.0)
Now dm8000 is still on because of bdremux process, but i switch amp/tv off, now when i switch amp/tv on their is no signal on dm dvi-d output, becasue the dm8000 cannot switch standby/on, probably because of bdremux process.
I try to view dm8000 by webinterface, but that doesn't connect.
I try to control dm8000 with telnet, but also no connection.
I don't want to hard restart the dm8000, because then i'm sure i interrupt the bdremux proces. So i just wait, and see when the dm8000 reacts on front power button press (to go in standby, and then press again to get on so that i have working dvi-d video output)

about 2 minutes after touching powerbutton (or remote button for bouquets) i get a working dvi-d videosignal. Seems that the dm8000 is getting very slow on responding.
At the moment i only see the animation in left upper corner of the spinning gear. it animates a few seconds, stops a few seconds animates again a few seconds, and so on.
2 minutes later i suddenly have working tv. still with the spinning gears in left upper corner. Dm8000 is very slow on commands, even countdown of a message is jammed, LOL.
Webinterface works, but the browser was waiting for a connection for about 4 minutes, and only for showing the login popup(username/password). (something that normally takes 1/4 th of a second)
I just let the dm8000 continue this way, maybe it's really busy with bdremux process

Zitat von Fraxinas

please upload a recording (.ts) file somewhere for me to test the bdremux process with
maybe it's a problem with the specific transponder

Ok, I uploaded about 423MB of HD recording here (click, select agree and then download) , it's a first part of the .ts file.
Remember that this is not the only recording that has issues with bdremux that seems to go sleeping.

Let me know when you downloaded it, because then i remove the .ts file.

Zitat von maoui

DM8000 and DM800 are currently not compatible with french terrestrial HD network .
can you add codec AC3+ ???
Again, could you please answer.
Thanks,

How about switching to French DVB-S2 provider or DVB-C ?
I mean a switch to satellite (or coax provider if available in your area) is faster then waiting for DD+ support on your dreambox.

Zitat von BOADIL

Totally i agree with you.

Then why did you buy a DM8000? The specs are clear .
Maybe their will be a plugin that converts AC3+ (DD+) to AC3/DD, just like the DTS plugin does originally from Openpli. Ask your used image builder.

Zitat von dhwz

the main target of using DD+ is to force customers to use the providers hardware...

So...hello marketing
Besides, i don't watch French channels (they refuse to talk English too LOL)