Recording via cifs with errors

[Sinobi]

Hi all

Recently I bought my 7020 (second hand), and it had a 200GB harddisk in it.
I have been recording and playing back on the harddisk a few times, all with success.
Yesterday the disk died on me (guess the machine gets too hot).
Today I therefor followed some of the guides on setting up a CIFS share on my XP server.
The setup went fine and I could mount and record.
BUT
When I playback the recording (either on the XP server or the 7020),
it plays like 2 seconds, then jump 5-8 seconds, plays 2 second again, jumps 5-8 seconds ect.
Why is this happening?

I have searched and found nothing.
Only one thread talked about that this could happen when you record coded channels via CIFS.
I therefor tried recording a FTA, but it showed the same problems.
Network is 100Mbit on a switch with no other traffic.
7020 is with PLI ioLite image.

Hope someone can help....
Best ect.
Henrik

[Sinobi]

I'm beginning to think that this may be related to a low speed on my dreambox netcard.
This because viewing the received channel over the LAN on a PC with either VLC or one of the dreambox managedment programs give me the same playback carateristics.

Any ideas on how I can test the speed of my dreambox LAN connection?

Henrik

[westkill]

you can do via telnet to test it
just tested mine

type ping then the ip of your dreambox
so it looks "ping 192.168.***.*** "

[Sinobi]

I hear you, but a ping will only test the exisistance and latency of a connection over LAN, not the actual transfererate.
Am I correct?
Anyway. It actually shows "time=" as "<1ms" 50% of the pings and "-706ms" the other 50% of pings.
So no clue in there.

Any other ideas?

Henrik

[Sinobi]

Just fell over an old thread about changing two capasitors related to the networking chip.
Thread states that if 7020 is an old model it has a Philips tuner rather than an Alps inside, and these old models had problems with very low network speed.
PLi? Images website (http://www.pli-images.org/modules/wiki/index.php?wakka=DM7020Lan)
A "ping xxx.xxx.xxx -t -l 26000" confirms that I have the problem (and I have also confirmed that I have the Philips tuner inside)
Actually I have to go below "ping xxx.xxx.xxx -t -l 512" to avoid timeout.
Will find some capasitors and solder them in to see if I can fix the problem.

Henrik

[robbieb43]

Hi Sinobi

I have trodden a similar path with my DM500 (clone) and actually bought some capacitors in preparation for a bit of surgery, but found that it had the right (capacitor) values when I got it open. May be worth a quick check before you buy therefore. Also if you are going ahead with the mod, make sure you have a good and fine temp controlled iron and good eyes!

In my various attempts at getting things working I found the protocol made quite a difference - seems that M$ have made a less than perfect job of implementing the CIFS interface. In the end, I found an old PIII laptop with Linux (ubuntu version on mine) with a SMB share worked fine - obviously meaning it was the CIFS on M$ causing the problem. I also tried the NFS server on W2K (see Dreambox tools for a good one) worked (ish) and NGRAB on W2K crashed all the time.

HTH


Rob

[Sinobi]

Thanks for the warning.
I was fairly sure that my 7020 version was the old one, as I both had the Philips tuner and the ping showed a huge network problem.
Also I opened up the DB and could see that the two capasitors matched the ones in the pictures.
Therefor I brought my DB with me to work today (I'm an electronic engineer in the Airforce)
and brought along an old defect Radeon 9800 graphics card with some capasitors that looked like the correct physical size.
After desoldering I meassured them, and they were 1.4uF.
I piggybaged them on top of the original ones, so result is 3.6uF.
I just tested the result an hour ago and......SUCCESS.
I now have stable response with ping xxx.xxx.xxx.xxx -t -l 32000
and recording over LAN works like a charm.

Henrik

[robbieb43]

Cool. As a matter of interest was that the two tiny SMT caps. Reason I asked is that I backed off once I saw the electrlytic was correct, but I suppose it is possible that the SMT ones are not. Sadly I have no real way of testing their value (I am afraid it's many years since I studied electronics - I assume I need a capacitance meter or a scope?).

I supose the learning point from our combined experiences is that the reason that their are so many people struggling with this (judged by the number of posts over the various DB groups) is that their are multiplle things that combine to slow it down. I guess I might find that if I tuned up my comms circuitry, I might find some of the failed protocols work.

Rob

[Sinobi]

Just judge them by the phisical size and compare them to the one in the second photo in the link I gave above. If they are smaller than the single capasitor, then they are too small and need an upsizing. If they are the same size, this part of the networking is OK.

Henrik

[robbieb43]

Thanks Henrik - the layout is a bit different in the DM500 and there is a electrolytic that tends to be a problems as well, but I think since the size test will apply for the two SMTs as it is the same comms chip.

Rob

[Sinobi]

I can't imagine that Dream made the same mistake twice (if I'm not mistaken the 500 is newer than 7020).
This fault with the undersized capasitors was fixed by Dream back in 2005 so newer models 7020 don't have that type of fault.
By doing the Ping test I mentioned above you can judge if your network out of the DM500 is in fact lacking the ability to transfere large blocks of data on a 100Mbit network without loosing it's breath.
If the ping test goes ok, you have to look elsewhere for the problem.
"Elsewhere" could very well be software related rather than hardware related.

Henrik