Posts by toysoft

Quote from jrcruz

image openatv 6.3

Try to install the current one, 7.5

openATV Nightly Downloads

You can also try our OpenPLi 9.xStar,

http://openpli9xstar.japhar.net/OpenPLi9xstar/openpli-enigma2-9xstar-dm520.rootfs.tar.xz

TS

Which image version/date it is ? As generally this could be due to old drivers, it's always better to install a recent image, which will have the latest drivers, and should work (if it ever worked on that box).

TS

Are you sure your sim is a Ferrari ? As Ferrari Sim supports only Kernel 2.6... and not 3.2,

Japhar with Ferrari Compatibility for DM800HDse, will support Ferrari 2.6 and Japhar 3.2 Kernel,

Image : http://openpli9xstar.japhar.ne…nigma2-9xstar-dm800se.nfi

BUT this only if your sim is a Japhar (and not Ferrari).

TS

Quote from slpx

This is the image in the box

System OE:	PLi-OE
Firmware version:	OpenPLi 7.3-release (2020-08-29-release-7.3)
Kernel / Drivers:	4.1.20 / 20190424

Im not receiving video in VU+. The channel can be seen in VLC though.

This is the codecs displayed in VLC

Channel Displayed. (https://ibb.co/4RJnz2SY)

Channel not displayed (https://ibb.co/6JYyLJR5)

What the image/version to use to view these channels.

Both channels Audio is hearable in both VU and VLC. Video is visible of both channels in VLC.

Appreciate any help

Display More

Did you do a scan or uploaded a pre-configured Channel List ? As this could be the reason, I always do a rescan after such thing of the satellite ou satellites.

TS

P.S.: Also you can try the OpenPLi 8.xStar for your box, which should work (We have many users having installed it). Remember that after first flash you need to let it do the full boot. Then turn off the box, and turn it on again, and only then the Drivers will work (first boot ever after flashing fails loading all drivers including the ones of the tuners...)

OpenPLi Release by OpenPLi Team, September 2024

- Python 3.9.9

- GStreamer 1.20.5

- FFMpeg 5.1.2 and Exteplayer3, ServiceApp (Dash Support, iCam via StreamRelay)

- EPGImport Built-in

- AC3+/DDP/EAC3 support

- Feeds online (For Wifi/DVB-T Dongles)

- DVB-T USB, Trial Tuner, from JAM (Hauppauge, A867, etc)

- Wifi Realtek, Ralink, Mediatek Supported

- CI+ and IPTV Support Built-in

1300 Free To Air FREE IPTV Channels from their broadcaster

100+ VoD Free To Air Public Domain Movies and more coming soon (Charlot, Keaton, etc)

VU+ Zero :

http://openpli8xstar.japhar.net/OpenPLi8xstar/openpli-8xstar-vuzero_usb.zip

Quote from Teslapolestar2

I keep getting the message:

“Your account is blocked, please contact your provider.”

Then after waiting about 10 seconds, the channel works anyway.

I’m using a Dreambox 900 RC20 model.

My provider says the issue is not on their side — the MAC address and everything else is correct.

This backup was originally running on a Dreambox UHD 900, not on an RC20 edition.

Everything else works fine.

Can you help me?

Display More

Your IPTV provider, is at fault,

TS

Search for Enigma1 images (for DM500s clone boxes),

TS

The latest one is available on the download address,

OpenPLi 8xStar IPTV - Our Dreambox World - Japhar Sim Forum - http://www.japhar.com/ - SuperSim3

TS

Quote from najar

Quote from toysoft

Quote from najar

Quote from toysoft

Quote from najar

Description:

Hello Enigma2 Development Community,

This post addresses a common and persistent issue with the timeshift functionality observed across a wide range of Enigma2-based set-top boxes when using a softcam for descrambling encrypted channels.

The Problem:

When a user is watching a scrambled channel with timeshift active and a specific viewing delay established (e.g., watching 15 seconds behind the live broadcast), if the softcam's descrambling process is temporarily interrupted (due to issues like ECM processing delays, softcam restarts, or brief upstream problems affecting decryption), the timeshift playback position invariably "jumps" forward once descrambling resumes. This jump significantly reduces or entirely negates the user's intended timeshift delay, often forcing playback بسیار close to, or at, the current live point of the broadcast. This behavior is consistently reported and impacts the usability of timeshift for many users.

Expected Behavior:

Ideally, the timeshift system should preserve the user-established viewing delay despite temporary descrambling interruptions. When descrambling capabilities are restored after a brief outage, the timeshift buffer should reflect the period of interruption (e.g., as a segment of black screen or undecryptable video). Subsequently, the clear, descrambled picture should resume, but the playback should continue with the original timeshift delay still intact relative to the ongoing live broadcast. The timeshift progress indicator should not exhibit a sudden forward leap that discards the accumulated delay.

Steps to Reproduce (General Scenario):

1. Activate timeshift on any scrambled television channel.
2. Establish a noticeable viewing delay (e.g., by pausing the live feed for several seconds and then resuming playback from the timeshift buffer).
3. Induce or wait for a temporary interruption in the softcam's descrambling process (this can be simulated by restarting the softcam, or it may occur naturally due to network/server latency if using cardsharing).
4. Allow the softcam and descrambling process to recover, and for the clear picture to return.
5. Observe that the timeshift playback position has advanced sharply, and the previously established viewing delay relative to the live broadcast has been substantially diminished or eliminated.

Additional Context and Suggestion:

This behavior significantly undermines the utility of the timeshift feature on encrypted channels, as transient descrambling issues can nullify the core benefit of the delay. The GStreamer framework, commonly used for playback, typically expects a well-formed input stream. The root of this issue appears to be how the Enigma2's DVB source handling and timeshift recording mechanism manage "data underflow" or "timeline discontinuities" that arise from the softcam when it cannot provide a continuous stream of descrambled data.

It is worth noting that some other (non-Enigma2) set-top box platforms incorporate features (sometimes marketed as "Video Delay" or similar) that successfully mitigate this problem. These systems appear to maintain the user's viewing offset by "padding" the timeshift buffer with placeholder data during decryption gaps, thereby preserving a more consistent timeline for the player.

We appeal to the Enigma2 development community to investigate potential enhancements to the timeshift recording and playback logic to better handle these common scenarios. One conceptual approach could involve the timeshift recorder inserting null TS packets (or a similar inert padding mechanism) into the timeshift file during periods of descrambling unavailability. The goal would be to maintain a temporally consistent data stream for the player, thus preventing the large jumps that currently occur, even if it means a period of unwatchable (padded) content within the buffer.

Addressing this issue would greatly improve the timeshift experience for a significant portion of the Enigma2 user base. Thank you for your consideration.

Display More

Will send your message to the various Teams of open images,

TS

Display More

Thank you very much. I hope you can help us find a solution because this is a problem for thousands of users, especially in the Middle East.

Display More

The main Team is working in a complete rewritting of Timeshift, I think that it will bring what is expected,

TS

Display More

Which team i can help with modification or explainattion

Display More

OpenATV would be the first one to talk with,

TS

STB (or App section decompiled) seems to be from

https://medianet.mv

TS

Medianet itself is a concept related to rich media delivery over a network, not an encryption algorithm. It's an architecture for networks optimized for delivering rich media experiences, not a specific encryption method. Medianet utilizes encryption to protect the media stream, but it's not the encryption algorithm itself. Cisco Systems defines medianet as an end-to-end architecture for a network.

Medianet, when used with platforms like Akamai, will utilize session-level encryption, meaning the stream is encrypted on a per-user session basis. This means the decryption key is unique for each session, and the stream is encrypted for each individual user's playback.

The specific encryption algorithm used in a Medianet environment can vary. Common algorithms include:

• AES (Advanced Encryption Standard): Often used in media encryption, particularly AES-128 and AES-256. Vonage uses AES-128 by default for media streams, with AES-256 available as an add-on.
• Other algorithms: Depending on the specific system and security requirements, other encryption algorithms might be used.

In summary: Medianet is an architecture for delivering rich media, and it uses session-level encryption to protect the media stream. The actual encryption algorithm used (e.g., AES) is separate from the Medianet concept itself

0960 card ?

TS

Quote from najar

Quote from toysoft

Quote from najar

Description:

Hello Enigma2 Development Community,

This post addresses a common and persistent issue with the timeshift functionality observed across a wide range of Enigma2-based set-top boxes when using a softcam for descrambling encrypted channels.

The Problem:

When a user is watching a scrambled channel with timeshift active and a specific viewing delay established (e.g., watching 15 seconds behind the live broadcast), if the softcam's descrambling process is temporarily interrupted (due to issues like ECM processing delays, softcam restarts, or brief upstream problems affecting decryption), the timeshift playback position invariably "jumps" forward once descrambling resumes. This jump significantly reduces or entirely negates the user's intended timeshift delay, often forcing playback بسیار close to, or at, the current live point of the broadcast. This behavior is consistently reported and impacts the usability of timeshift for many users.

Expected Behavior:

Ideally, the timeshift system should preserve the user-established viewing delay despite temporary descrambling interruptions. When descrambling capabilities are restored after a brief outage, the timeshift buffer should reflect the period of interruption (e.g., as a segment of black screen or undecryptable video). Subsequently, the clear, descrambled picture should resume, but the playback should continue with the original timeshift delay still intact relative to the ongoing live broadcast. The timeshift progress indicator should not exhibit a sudden forward leap that discards the accumulated delay.

Steps to Reproduce (General Scenario):

1. Activate timeshift on any scrambled television channel.
2. Establish a noticeable viewing delay (e.g., by pausing the live feed for several seconds and then resuming playback from the timeshift buffer).
3. Induce or wait for a temporary interruption in the softcam's descrambling process (this can be simulated by restarting the softcam, or it may occur naturally due to network/server latency if using cardsharing).
4. Allow the softcam and descrambling process to recover, and for the clear picture to return.
5. Observe that the timeshift playback position has advanced sharply, and the previously established viewing delay relative to the live broadcast has been substantially diminished or eliminated.

Additional Context and Suggestion:

This behavior significantly undermines the utility of the timeshift feature on encrypted channels, as transient descrambling issues can nullify the core benefit of the delay. The GStreamer framework, commonly used for playback, typically expects a well-formed input stream. The root of this issue appears to be how the Enigma2's DVB source handling and timeshift recording mechanism manage "data underflow" or "timeline discontinuities" that arise from the softcam when it cannot provide a continuous stream of descrambled data.

It is worth noting that some other (non-Enigma2) set-top box platforms incorporate features (sometimes marketed as "Video Delay" or similar) that successfully mitigate this problem. These systems appear to maintain the user's viewing offset by "padding" the timeshift buffer with placeholder data during decryption gaps, thereby preserving a more consistent timeline for the player.

We appeal to the Enigma2 development community to investigate potential enhancements to the timeshift recording and playback logic to better handle these common scenarios. One conceptual approach could involve the timeshift recorder inserting null TS packets (or a similar inert padding mechanism) into the timeshift file during periods of descrambling unavailability. The goal would be to maintain a temporally consistent data stream for the player, thus preventing the large jumps that currently occur, even if it means a period of unwatchable (padded) content within the buffer.

Addressing this issue would greatly improve the timeshift experience for a significant portion of the Enigma2 user base. Thank you for your consideration.

Display More

Will send your message to the various Teams of open images,

TS

Display More

Thank you very much. I hope you can help us find a solution because this is a problem for thousands of users, especially in the Middle East.

Display More

The main Team is working in a complete rewritting of Timeshift, I think that it will bring what is expected,

TS

Quote from najar

Description:

Hello Enigma2 Development Community,

This post addresses a common and persistent issue with the timeshift functionality observed across a wide range of Enigma2-based set-top boxes when using a softcam for descrambling encrypted channels.

The Problem:

When a user is watching a scrambled channel with timeshift active and a specific viewing delay established (e.g., watching 15 seconds behind the live broadcast), if the softcam's descrambling process is temporarily interrupted (due to issues like ECM processing delays, softcam restarts, or brief upstream problems affecting decryption), the timeshift playback position invariably "jumps" forward once descrambling resumes. This jump significantly reduces or entirely negates the user's intended timeshift delay, often forcing playback بسیار close to, or at, the current live point of the broadcast. This behavior is consistently reported and impacts the usability of timeshift for many users.

Expected Behavior:

Ideally, the timeshift system should preserve the user-established viewing delay despite temporary descrambling interruptions. When descrambling capabilities are restored after a brief outage, the timeshift buffer should reflect the period of interruption (e.g., as a segment of black screen or undecryptable video). Subsequently, the clear, descrambled picture should resume, but the playback should continue with the original timeshift delay still intact relative to the ongoing live broadcast. The timeshift progress indicator should not exhibit a sudden forward leap that discards the accumulated delay.

Steps to Reproduce (General Scenario):

1. Activate timeshift on any scrambled television channel.
2. Establish a noticeable viewing delay (e.g., by pausing the live feed for several seconds and then resuming playback from the timeshift buffer).
3. Induce or wait for a temporary interruption in the softcam's descrambling process (this can be simulated by restarting the softcam, or it may occur naturally due to network/server latency if using cardsharing).
4. Allow the softcam and descrambling process to recover, and for the clear picture to return.
5. Observe that the timeshift playback position has advanced sharply, and the previously established viewing delay relative to the live broadcast has been substantially diminished or eliminated.

Additional Context and Suggestion:

This behavior significantly undermines the utility of the timeshift feature on encrypted channels, as transient descrambling issues can nullify the core benefit of the delay. The GStreamer framework, commonly used for playback, typically expects a well-formed input stream. The root of this issue appears to be how the Enigma2's DVB source handling and timeshift recording mechanism manage "data underflow" or "timeline discontinuities" that arise from the softcam when it cannot provide a continuous stream of descrambled data.

It is worth noting that some other (non-Enigma2) set-top box platforms incorporate features (sometimes marketed as "Video Delay" or similar) that successfully mitigate this problem. These systems appear to maintain the user's viewing offset by "padding" the timeshift buffer with placeholder data during decryption gaps, thereby preserving a more consistent timeline for the player.

We appeal to the Enigma2 development community to investigate potential enhancements to the timeshift recording and playback logic to better handle these common scenarios. One conceptual approach could involve the timeshift recorder inserting null TS packets (or a similar inert padding mechanism) into the timeshift file during periods of descrambling unavailability. The goal would be to maintain a temporally consistent data stream for the player, thus preventing the large jumps that currently occur, even if it means a period of unwatchable (padded) content within the buffer.

Addressing this issue would greatly improve the timeshift experience for a significant portion of the Enigma2 user base. Thank you for your consideration.

Display More

Will send your message to the various Teams of open images,

TS

Quote from trepqa89

I order this one:
Dreambox One Combo Ultra HD 1x DVB-S2X MIS 1xDVB-C/T2 Tuner 4K 2160p E2 Linux Dual WiFi H.26

The price was 140 EUR at Amazon.de

It should work with satellite channels?

Regards

Display More

Yes, it's Sat box (Combo Tuner, so 1 x Sat and 1 x C/T2),

TS

Quote from trepqa89

Quote from toysoft

What do you want to do with it ? Which purpose, which type of channels, DVB-T2 ? DVB-S2/S2X ? DVB-C ?

As the DM500HD is still good, with the right image (and if you have an USB port, you can move some of the image into it).

TS

I want to watch satellite channels only and IPTV if possible!

I want a stable reciver that I can use many years!

Display More

For me, I would go today with this one, the proposal of the member before, I think, is just good, it's equivalent to a DM900UHD/DM920UHD, same or very similar (you can compare, seems to be from same OEM manufacturer)...

AB PULSe 4K Rev. II (2XS2X) | Abcom.tv

abcom.tv

TS

Quote from trepqa89

Quote from toysoft

What do you want to do with it ? Which purpose, which type of channels, DVB-T2 ? DVB-S2/S2X ? DVB-C ?

As the DM500HD is still good, with the right image (and if you have an USB port, you can move some of the image into it).

TS

I want to watch satellite channels only and IPTV if possible!

Display More

Then any Enigma2 box is good now, if you use open images for it, also your old DM500HD... dead or you just want to change ? As it is still good with openpli, for watching SAT + IPTV/Streaming.

TS

Quote from Omiros Savvidis

Quote from toysoft

DM920UHD: OpenPLi 9.xStar 20250115 GSt 1.20.5

openpli-enigma2-9xstar-dm920.root.tar.bz2

Выпуск OpenPLi от команды OpenPLi, январь 2025 г.

- Питон 3.9.9

- GStreamer 1.20.5

- FFMpeg 5.1.2 и Exteplayer3, ServiceApp (поддержка Dash, iCam через StreamRelay)

- Встроенный импорт EPG

- Поддержка AC3+/DDP/EAC3

- Онлайн-каналы (для Wifi/DVB-T-модемов)

- DVB-T USB, пробный тюнер от JAM (Hauppauge, A867 и т.д.)

- Поддержка Wi-Fi Realtek, Ralink, MediaTek

- Встроенная поддержка CI+ и IPTV

1300 бесплатных каналов IPTV от их вещателя

Более 100 бесплатных фильмов VoD в общественном достоянии, и скоро появятся новые фильмы (Шарлот, Китон и т. д.)

DM920UHD:

Code

http://openpli9xstar.japhar.net/OpenPLi9xstar/openpli-enigma2-9xstar-dm920_web.zip

Для вашего сведения: каналы будут доступны в воскресенье вечером, изображения доступны по адресу http://openpli9xstar.japhar.net/OpenPLi9xstar/

Display More

ДОБРЫЙ ДЕНЬ КАК ОБНОВИТЬ ЭТУ ПРОШИВКУ

Display More

Via the feeds, opkg update + opkg upgrade

or reflashing the lastest image compiled available at

OpenPLi 9xStar IPTV - Our Dreambox World - Japhar Sim Forum - http://www.japhar.com/ - SuperSim3

Quote from satfreund

How about this receiver?

Display Spoiler

https://abcom.tv/en/product/sa…-4k-rev-ii-2xs2x-29387507

at what I was told it's like a DM900UHD/DM920UHD, so very good and high end, and versatile box, supported by OpenATV, which is very good.

TS

What do you want to do with it ? Which purpose, which type of channels, DVB-T2 ? DVB-S2/S2X ? DVB-C ?

As the DM500HD is still good, with the right image (and if you have an USB port, you can move some of the image into it).

TS

There is a script (full packages I publised to backup any DMM box and image), this addon is not supporting properly these new boxes,

See below,

https://mega.nz/file/sFk0DQKZ#RwQMBaz2dRxhJx_jJJ8MY1a-l_1GdeR7a9wjaioIUtU

Topic about the scripts

http://www.ourdreambox.com/ubbthreads.php?ubb=showflat&Number=25623&an=75#Post25623

and Fairbird did this as well,

http://www.ourdreambox.com/ubbthreads.php?ubb=showflat&Number=17543#Post17543

TS

You probably need to install some extra modules,

ModuleNotFoundError: No module named 'PIL'

TS