Perfect 500 streaming

[dweeb4]

I agree Senor, I was slightly dissappointed that they weren't completely error free as the streaming is visually perfect. I purposely left the PC alone while I did the first recording so as not to push the CPU, so I don't know what caused these errors - all bunched around a small time window. It seems to indicate some activity or event on 500 or PC which caused it? The second, shorter recording I was using the PC quite intensively!

Anyway, have sent the analysis to developer

 

[señor ding dong]

I agree Senor, I was slightly dissappointed that they weren't completely error free as the streaming is visually perfect.

Yes, unfortunately experience has taught me not to trust the human eye for detail, even my own. Even though you might not notice break-up or corruption while viewing, it doesn't mean it isn't there. I have heard lots of people claim they have perfect recordings, and then found a few thousand with MPEG2repair, which were then easy to spot once you knew what to look for and where, but they can easily get lost in dark areas or sequences with lots of motion. Also, some playback codecs on the PC will display corruption differently, sometimes just freezing that part of the image, which can make it impossible to detect with the naked eye.

 

[dweeb4]

Nonetheless, Senor, as far as streaming is concerned, this is a major advance over the stuttering, blocky, pixellated picture of the standard module.

And if these errors, reported by Mpeg2Repair, are visually benign, as they are in the streaming, then I'm a happy camper - I'll settle for that standard of recording.

My issue with recordings before was that the errors could be of any severity, causing no visual problem or freezing the picture. I'm a pragmatist - I think it's good enough now!

 

[señor ding dong]

Nonetheless, Senor, as far as streaming is concerned, this is a major advance over the stuttering, blocky, pixellated picture of the standard module.

And if these errors, reported by Mpeg2Repair, are visually benign, as they are in the streaming, then I'm a happy camper - I'll settle for that standard of recording.

My issue with recordings before was that the errors could be of any severity, causing no visual problem or freezing the picture. I'm a pragmatist - I think it's good enough now!

As long as you're happy with its performance, that's cool, and for just general streaming/viewing, I would probably agree, but I won't settle for less than perfection when it comes to recordings, because I know it's possible on my supposedly inferior Dbox2, which actually happens to outperform the wildly overrated DM500 in virtually all the important areas.

 

[pt-1]

Regarding the EPG, FreddyFrog has posted in some other Forums a plugin that enables to download the EPG Data for UK Sat 28.2 users and use it within Neutrino.

No Extra PC needed and Neutrino let's you program the Timer or record via the Webinterface

 

[dweeb4]

As long as you're happy with its performance, that's cool, and for just general streaming/viewing, I would probably agree, but I won't settle for less than perfection when it comes to recordings, because I know it's possible on my supposedly inferior Dbox2, which actually happens to outperform the wildly overrated DM500 in virtually all the important areas.

Ah, your a perfectionist - no harm in that. Indeed, if/when a fully fledged solution is realised, I'll be one of the first using it as I'm sure you will also.

As you can see from my posts I've been pushing for some analysis of the underlying problems associated with 500 recording. Would love to open this up for dsicussion but I don't see too many takers.

 

[loady]

I think your determination is an inspiration, i think though that after senors extensive recording tests the conclusion was made that the hardware (chips) just cant handle the pace and that unless you could somehow upgrade these parts then we are stuck with flawed recording...lets hope you can prove otherwise. Good luck dweeb

 

[dweeb4]

I think your determination is an inspiration, i think though that after senors extensive recording tests the conclusion was made that the hardware (chips) just cant handle the pace and that unless you could somehow upgrade these parts then we are stuck with flawed recording...lets hope you can prove otherwise. Good luck dweeb

Hi Loady,
Thanks, but I don't think there was such a conclusion on Senor's thread - it was stated that hardware was the problem BUT I have been putting forward the argument which contradicts this - the 600 is the same hardware as the 500 (except for IDE chips) but it can produce flawless recording over the network. So I can only conclude that software is the issue!

I believe that the Zapstream software proves some of this i.e. a new software module to replace the existing streamts module in the original image has such a profound improvement on streaming.

Now it may be that it comes down to closed source software that we have no ability to interrogate/amend? But I don't believe we are at that point yet!

Some areas that should be looked into and need to be considered are:
- How is the 600 software different to the 500?
- I'm told the 600 image is uses Linux 2.6.12, the dm500 uses 2.6.9. So this could be where the problem is? There is some recent efforts to to use 2.6.12 on the dm500 here: http://www.i-have-a-dreambox.com/wbb2/thread.php?threadid=74187&hilightuser=29701

Again, as I was told that recording/networking are not functions which were designed into the original image so we are pushing the envelope here, with some success so far.

 

[T4i]

Since reading this i've tried upgrading from my DIORJ 0.6 to the newest Pli image, would love to try out this improved recording ability, but i cqn't for the life in me get the image working with certain channels

God knows what i'm doing wrong....

 

[dweeb4]

Do you mean only FTA channels working? I use Evocamd 2.14 & it's fine.

Just remember Helenite image has the old Zapstream module which isn't as flawless as the updated module. Try it & tell us what you think.

Also remember that it's for streaming to PC, not recording. I'm recording the stream using VLC script I gave in the thread to both stream & record at the same time.

I haven't asked the developer yet for permission to post the module here for downloading but I'm sure he wouldn't mind a second tester. PM me

He is completing the last aspects of this, configuration options for delay's, buffersizes, etc..

 

[señor ding dong]

Hi Loady,
Thanks, but I don't think there was such a conclusion on Senor's thread - it was stated that hardware was the problem BUT I have been putting forward the argument which contradicts this - the 600 is the same hardware as the 500 (except for IDE chips) but it can produce flawless recording over the network. So I can only conclude that software is the issue!

Yes, I didn't make an absolute conclusion that the hardware was at fault, I'm not qualified to do so. PT-1 was the one who stated that an underpowered demux chip was to blame, of course, and considering his track record of impeccable credibility on these matters, I accepted this explanation. I don't know enough about the architecture of the box and chipset to say that you're right or wrong about it being the same, but I am quite certain you're right that software plays at least a part, due to the substantial differences between Neutrino and Enigma images. Whether or not the software can be tweaked further to squeeze a little bit extra out of what may indeed be an underpowered chipset isn't for me to say, but I would expect that Enigma based images could at least be brought up to Neutrino standards, where disabled playback can produce perfect recordings.

 

[pt-1]

We also musn't forget that to "us" the Hardware looks the same but we are not really professionals to check this out as they could have changed certain layouts that can be seen if only under a microscope etc.

Also there are underlying drivers running as an interface between enigma/neutrino and the Hardware itself.

But I really like the determination to find a fix for this issue as unfortunately most of the uk box scene only want's free TV and is not really willing to try anything. The people who do know that I am not adressing them !

 

[dweeb4]

I agree with both of you Senor & pt-1, I'm pushing the software as a solution but at the same time I realise that it might well be a hardware/software combination issue which we can only progress so far.

Indeed, pt-1, I agree with you that the 600 hardware might be visibly the same as the 500 but the circuit could be different. I don't have one to check but it wouldn't require a microscope just a good set of eyes & a lot of patience to trace the pcb tracks & convert to a schematic (easier said than done)

I just rallied against the suggestion offered by DM (reported by pt-1), that it was a an underpowered chip, (I had already tried the capacitor solution) and there's nothing we can do about it. And I asked some questions like where is the demux chip, what about he 600 hardware, etc? All of which indicated that this explanation was wrong or at least flawed.

Anyway, as I said above the Zapstream module proves that significant improvement is possible through software. Now to try & address the recording software & see what can be done!

 

[dweeb4]

Some people asked me to send them the streamts module as it can be used with any image not just PLi Helenite. I can't post the Zapstream module here as the developer hasn't yet put it in the public domain !

It's easier to post streamts it here & the instructions for it's use:

1) Copy streamts to /var/sbin/
2) Copy inetd.conf to /var/etc/
3) telnet to your DM500
4) chmod 755 /var/bin/streamts

5) ps
6) kill < pid for inetd > ( use the pid shown in ps )
7) inetd /var/etc/inetd.conf

Try it & let's know your experiences!

 

[dweeb4]

If anybody is using the Gemini V4.0 image - I would be interested to see an analysis of a recording done with display turned off and the new streamts module being used. Use the following VLC command to record:

"c:\Program Files\VideoLAN\VLC\vlc.exe" http://192.168.0.24:31339 :sout=#duplicate{dst=display,dst=std{access=file,mux=ts,url=c:\jfk.ts}}

 

[velvitjester69]

Some people asked me to send them the streamts module as it can be used with any image not just PLi Helenite. I can't post the Zapstream module here as the developer hasn't yet put it in the public domain !

It's easier to post streamts it here & the instructions for it's use:

1) Copy streamts to /var/sbin/
2) Copy inetd.conf to /var/etc/
3) telnet to your DM500
4) chmod 755 /var/bin/streamts

5) ps
6) kill < pid for inetd > ( use the pid shown in ps )
7) inetd /var/etc/inetd.conf

Try it & let's know your experiences!

when im at the stage 6,there is no inetd in the list,the kill command is not recognesed

 

[pt-1]

I agree with both of you Senor & pt-1, I'm pushing the software as a solution but at the same time I realise that it might well be a hardware/software combination issue which we can only progress so far.

Indeed, pt-1, I agree with you that the 600 hardware might be visibly the same as the 500 but the circuit could be different. I don't have one to check but it wouldn't require a microscope just a good set of eyes & a lot of patience to trace the pcb tracks & convert to a schematic (easier said than done)

I just rallied against the suggestion offered by DM (reported by pt-1), that it was a an underpowered chip, (I had already tried the capacitor solution) and there's nothing we can do about it. And I asked some questions like where is the demux chip, what about he 600 hardware, etc? All of which indicated that this explanation was wrong or at least flawed.

Anyway, as I said above the Zapstream module proves that significant improvement is possible through software. Now to try & address the recording software & see what can be done!

Some of us might even remember the good old Comodore C64 were the manufacturer said that only 8 Sprites are possible .... They have been proved wrong but that is a long while ago ;-)

 

[dweeb4]

Jeez, pt-1 that's going back a bit, unfortunately, I remember the C64's!

Hi Velvitjesters69, are you running Helenite? Should be a inetd process in the PS list - try to take a screen snapshot & post by dragging open a box around the PS output & press CTRL/C to copy

 

[dweeb4]

I'm trying the DS Team 3.2 image because it's based on the latest CVS, I could find:

+ CVS 20.06.2007
+ kernel v. 2.6.9 (1.10)
+ enigma v. 1.10 Mod (20.06.2007 mod DS Team)
+ BusyBox v1.01 (2007.06.20-14:09+0000 mod DS Team)
+ Web Interface: 6.02-Expert mod DS
+ Gcc 3.4.4
+ FP Firmware 1.06
+ LZMA Patch

Is anybody else using this? Does anybody know an image based on later CVS?

 

[velvitjester69]

Jeez, pt-1 that's going back a bit, unfortunately, I remember the C64's!

Hi Velvitjesters69, are you running Helenite? Should be a inetd process in the PS list - try to take a screen snapshot & post by dragging open a box around the PS output & press CTRL/C to copy

digital worldz 1.6.5