104 replies to this topic

[Roodkapke]

It's mentioned on other forums before that the recording-stream that comes out of your box isn't a stream but many bursts of data. You won't get a constant stream.
I have a 7000, a 600 and a 500. I got the best results with smbfs.
CIFS refused to give me resonable recordings.
And i don't use cheapo networkmaterial.

With the help of some great guys streaming as become a lot better, but still not flawless.
Somehow the 7000 is better designed, and is able to perform better.
Maybe the new 500+ is a little better, i will try one soon.

[RedFury]

True. Packet loss during streaming is ignored.
When recording, there is a constant negotiation going on between cliend server about the integrety of the received data.
This places more stress on the CPU of both machines and, if not handled on time, the "stream" gets corrupted more notably then
during streaming.

This raises a question, because the mount manager of PLi WebIF had an UDP checkbox.
One would assume that this terminates the integrity checks (aka the TCP part if TCPIP) and just dumps it's data
onto the network. (Just like streaming).

Does someone know if this checkox has any effect?

Roodkapje: What server/device do you use to record the stream onto?

[pieterg]

udp setting only works for nfs, afaik

[pieterg]

btw, with udp I assume nfs implements it's own checksums / retransmissions, so the question is whether it does a better job than tcp.

[RedFury]

Ah! The only drawback is that I have never heard good recordings from people using NFS.
Please correct me if I'm wrong.

[dweeb4]

Hi Redfury, Some results:
~ > ifconfig
eth0 Link encap:Ethernet HWaddr 00:09:34:1F:90:31
inet addr:192.168.0.24 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:785 errors:0 dropped:0 overruns:0 frame:0
TX packets:612 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:496281 (484.6 KiB) TX bytes:181507 (177.2 KiB)
Interrupt:25 Base address:0x600

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:100 (100.0 TX bytes:100 (100.0

~ >
~ > mount
/dev/root on / type squashfs (ro)
none on /dev type devfs (rw)
/proc on /proc type proc (rw,nodiratime)
devpts on /dev/pts type devpts (rw)
/dev/mtdblock/1 on /var type jffs2 (rw,noatime)
none on /tmp type ramfs (rw)
//bla on /hdd type cifs (rw,nodiratime,unc=\192.168.0.25\db,username=johnk,doma
n=,rsize=4100,wsize=4100)

1 root 536 S init
2 root SWN [ksoftirqd/0]
3 root SW< [events/0]
4 root SW< [khelper]
5 root SW< [kblockd/0]
6 root SW [pdflush]
7 root SW [pdflush]
9 root SW< [aio/0]
8 root SW [kswapd0]
10 root SW [cifsoplockd]
11 root SW [mtdblockd]
13 root 536 S init
14 root 536 S /bin/sh /etc/init.d/rcS
22 root SW< [fe_thread]
31 root SWN [jffs2_gcd_mtd1]
51 root 620 S /sbin/inetd
87 root 9424 S /bin/enigma
90 root 9424 S N /bin/enigma
91 root 9424 S N /bin/enigma
92 root 9424 S /bin/enigma
111 root 9424 R N /bin/enigma
119 root 9424 S N /bin/enigma
94 root 1008 S /var/bin/evocamd.ppc
116 root SW [cifsd]
120 nobody 780 S in.ftpd
122 root 812 S in.ftpd
123 root 424 S telnetd
124 root 708 S -sh
128 root 636 R ps -a

~ > lsmod
Module Size Used by
head 375384 31 - Live 0xc38cc000

Hope this helps & you can tell me something about my configuration!

[dweeb4]

Oops, I just realised this is a different image that I loaded last night Peter_Pan_Neverland_Fix (contains new streamts). Sorry about that - I'll load Pli Helenite image & post the same results soon. I don't know if you can tell anything from these figures but I notice that the CIFS mount isn't reported properly the PC folder is "db" not "bla" and rsize & wsize is 4096, not 4100

[dweeb4]

root@dreambox ~ # ifconfig
eth0 Link encap:Ethernet HWaddr 00:09:34:1F:90:31
inet addr:192.168.0.24 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:211 errors:0 dropped:0 overruns:0 frame:0
TX packets:106 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:83386 (81.4 KiB) TX bytes:12709 (12.4 KiB)
Interrupt:25 Base address:0x600

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:200 (200.0 TX bytes:200 (200.0

root@dreambox ~ # mount
/dev/root on / type squashfs (ro)
none on /dev type devfs (rw)
/proc on /proc type proc (rw,nodiratime)
devpts on /dev/pts type devpts (rw)
/dev/mtdblock/1 on /var type jffs2 (rw,noatime)
none on /tmp type ramfs (rw)
//192.168.0.25/db on /mnt/server1 type cifs (rw,nodiratime,unc=\192.168.0.25\db
username=johnk,rsize=4096,wsize=4096)
/dev/mtdblock/1 on /var_flash type jffs2 (rw,noatime)

4 root SW< [khelper]
5 root SW< [kblockd/0]
6 root SW [pdflush]
7 root SW [pdflush]
9 root SW< [aio/0]
8 root SW [kswapd0]
10 root SW [mtdblockd]
12 root 540 S init
13 root 544 S /bin/sh /bin/start_enigma
20 root SW< [fe_thread]
22 root SW [cifsoplockd]
23 root SW [cifsdnotifyd]
33 root SWN [jffs2_gcd_mtd1]
57 root SW [cifsd]
78 root 612 S /sbin/inetd
84 root 624 S crond
90 root 760 S /bin/pli_ecmhelper
104 root 10380 S /bin/enigma
107 root 10380 S N /bin/enigma
108 root 10380 S N /bin/enigma
109 root 10380 S /bin/enigma
112 root 964 S /bin/plimgr -l /dev/null
113 root 896 S /bin/plimgr -l /dev/null
124 root 976 S evocamd
141 nobody 788 S in.ftpd
143 root 816 S in.ftpd
144 root 432 S telnetd
145 root 708 S -sh
151 root 644 R ps -a

root@dreambox ~ # lsmod
Module Size Used by Tainted: P
cifs 245208 1 - Live 0xc4001000
head 384896 13 - Live 0xc38de000

[RedFury]

Correct. Try to use powers of 8 for the buffers.

I also see that you use evocam. Can you try it with the build-in CCcam perhaps?
Also, can you report the 'ifconfig' output after you made a couple of minutes recording.
Maybe we can see some frame errors there.

[dweeb4]

Still using evocamd - Here's a summary analysis of a short recording:

File Size Processed: 523.67 MB, Play Time: 00h:15m:53s
720 x 576, 25.00 fps, 8.00 Mbps (3.91 Mbps Average).
Average Video Quality: 19.45 KB/Frame, 0.38 Bits/Pixel.
MPEG Audio.
52 of 23432 video frames found with errors.
0 of 0 audio frames found with errors.
370226 corrupted video bytes in file.

And the ifconfig:
root@dreambox ~ # ifconfig
eth0 Link encap:Ethernet HWaddr 00:09:34:1F:90:31
inet addr:192.168.0.24 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:276665 errors:0 dropped:0 overruns:0 frame:0
TX packets:412190 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:27756890 (26.4 MiB) TX bytes:590841777 (563.4 MiB)
Interrupt:25 Base address:0x600

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:200 (200.0 TX bytes:200 (200.0

No packets dropped,etc

[dweeb4]

Change to CCam - short recording on FTA channel

Sequence Summary:

File Size Processed: 207.82 MB, Play Time: 00h:07m:06s
720 x 576, 25.00 fps, 15.00 Mbps (3.51 Mbps Average).
Average Video Quality: 17.25 KB/Frame, 0.34 Bits/Pixel.
MPEG Audio.
26 of 10586 video frames found with errors.
0 of 0 audio frames found with errors.
52232 corrupted video bytes in file.

root@dreambox ~ # ifconfig
eth0 Link encap:Ethernet HWaddr 00:09:34:1F:90:31
inet addr:192.168.0.24 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:642371 errors:0 dropped:0 overruns:0 frame:0
TX packets:962342 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:62318032 (59.4 MiB) TX bytes:1379814252 (1.2 GiB)
Interrupt:25 Base address:0x600

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:200 (200.0 TX bytes:200 (200.0

Can't see anything obvious!

[RedFury]

Hmm. I see that you have only a relative small number of corrupt frames.
When you view this recording, is this visible?
When i do recordings with my DM500 the stream is also no 100% perfect,
but these errors (mostly) aren't visible.

Is the recorded stream really too ugly to watch?
If so, does this also occur when you playback the recorded stream on your PC with VLC?

[dweeb4]

Small no of corrupt frames BUT ony 7 mins of recording & 26 corrupt frames same ratio as previous 52 frames in 15 min.

On playback with VLC frames pause and picture pixellates - not good enough to want to keep recording. Remember the only reason I want to record is for keeping

[RedFury]

No i'm not giving up, I'm just thinking...:smt012: ....:smt017....#-o#-o

[dweeb4]

Let me just interject in your thinking a moment & tell you that I have a software solution working perfectly streaming to Web-x-TV. This was a choppy, pixellated unreliable stream before this software so my money is on a software solution for recording also.

[RedFury]

I'm with you.
But I don't hope it's a DMM driver problem, because then there is nothing more I can do for you.
Since you already checked everything else.

The only problem I have is the fact that I'm using the same software set you do.
So why it it I don't have this problem?

We are both using PLi Helenite final version, and both the same emu's. Both no other plugins, both the same buffers, CIFS settings etc.
That is what's occupying my mind.

[dweeb4]

Have you analysed you recordings with Mpeg2Repair to check for errors?

[dispatcher]

Small no of corrupt frames BUT ony 7 mins of recording & 26 corrupt frames same ratio as previous 52 frames in 15 min.

Even worse: The average bitrate of the first recording is about 15% higher than that of the second recording. When you're that close to a perfect recording it comes down to percentages like that. And although it may not seem significant in terms of bitrate, the number of audiostreams (and an AC3 audiostream) can also produce just enough overhead to cause videoframe errors.

Would be nice if only the selected audio stream would be recorded and the rest would be dropped. This could be the reason why Ngrab/ggrab recordings have fewer errors.

[RedFury]

I will post the mpeg2repair output of a Premiere recording here soon. This stream will contain 2 stereo streams, and an AC3 stream.

[dweeb4]

It's mentioned on other forums before that the recording-stream that comes out of your box isn't a stream but many bursts of data. You won't get a constant stream.
I have a 7000, a 600 and a 500. I got the best results with smbfs.
CIFS refused to give me resonable recordings.
And i don't use cheapo networkmaterial.

With the help of some great guys streaming as become a lot better, but still not flawless.
Somehow the 7000 is better designed, and is able to perform better.
Maybe the new 500+ is a little better, i will try one soon.

With the (near) flawless version of streaming software that I have, one thing I noticed immediately is how much more constant is the flow over the network during streaming. It no longer is as bursty as before. Of course it fluctuates but whereas before I might have 1MByte & then the next second 300KBytes, now I have much more like a constant 600KBytes with smaller fluctuations.

I wonder is this a symptom showing the heart of the problem?