[7025] Opnames gaan hikken na +/- 1 uur opnemen (corrupte .TS file)

[Gast]

Korte probleem omschrijving:

Gemini 3 of nieuwste LT Image: Elke willekeurige opname zorgt na ca 1 uur opnemen voor een zeer hoge CPU load op de linux server. 2 of meer opnames starten, na ca 1 uur zelfde probleem. (dus niet sneller, zoals je misschien zou denken!)

Aan de ontvangst ligt het niet, als ik live meekijk naar het opgenomen kanaal is er helemaal niets mis mee.

Dit probleem heb ik niet in Gemini 2.0

Gemini 2.1 tot 3 heb ik niet geprobeerd.

 

Mijn huidige setup:

- Dreambox 7025, gemini 2.0, zonder HDD maar een mount met CIFS naar een samba share op:

- Linux server, CentOS4, PIII600. (was een celeron 333MHz ik dacht eerst dat die het niet (meer) trok)

- Mount settings: fstype=cifs,rw,soft,user=dreambox7025,password=secret ://876.564.951.642/share (ook geprobeerd met "async,nolock,rsize=16384,wsize=16384" -- wel snelheidswinst maar geen oplossing voor het probleem)

- Netwerk: 100Mbps bedraad.

 

Uitgebreidde omschrijving:

Ik heb met de nieuwste gemini (3) en LT images een vreemd probleem, wat ik bij Gemini 2.0 niet heb.

Als ik een opname start, dan gaat dat goed. Ik kan meerdere kanalen tegelijk opnemen en kijken, zonder een enkel probleem.

Maar; als er 1 opname langer dan ongeveer een uur loopt, dan gebeurd er ergens iets wat ik niet kan herleiden. Mijn linux server gaat naar zo'n 100% cpu (smbd doet dat) en de opname word niet goed meer naar schijf geschreven, waarschijnlijk als gevolg van die 100% cpu. I/O waiting stijgt gelijk met die 100% ook aanzienlijk. De opname blijft wel opnemen maar schrijft een corrupte TS file. Bij het bekijken van die TS file, gaat het kijken dus ook het eerste uur goed, daarna eerst een enkele dropout, snel steeds vaker en uiteindelijk is er geen kijken meer aan. Eerst dacht ik dat het bij het afspelen misging, maar de dropouts zitten altijd op dezelfde plek, ook als ik via software op de computer kijk. Dus kan je vaststellen dat het bij het opnemen helemaal fout is gegaan. Dit is overigens niet soms, het gaat altijd fout. Bij elke opname!

Ik heb mezelf een bult gezocht, samba geupdate, 'nieuwe' server neergezet, getweaked. Niets hielp. Erge is dat het dus niet effe snel te testen is, aangezien het alleen maar na ongeveer 1 uur voorkomt als ik met m'n dreambox iets (of meerdere kanalen) opneem.

Een 4 GB filecopy (ook vanaf de dreambox) bv gaat wel goed en levert geen hoge CPU/IOWaiting load.

Na veel wikken en wegen terug gegaan naar Gemini 2.0, daarvan wist ik dat ik dat probleem nog niet had. En inderdaad, daar werkt het allemaal prima.

Het ligt dus niet aan m'n server en/of netwerk.

 

Met gemini 2 kan ik 1 of meerdere streams (tot 4 getest) opnemen en 1 kijken. Dit kan uren achter elkaar (4 uur getest) zonder een enkel probleem. De CPU load op de server is dan zeer acceptabel, onder de 20% (smbd), IO Waiting piekt af en toe naar 30% maar over het algemeen zit ie onder de 15%. Daar heeft hij (ondanks dat het een PIII 600 is) dus geen moeite mee. Fluitend serveerd hij mij ook nog e-mail en de 'Mijn documenten' map.

 

Ik vermoed dat er ergens tussen Gemini 2.0 en 3.0 een nieuwere CIFS module is gebruikt in Enigma. En die nieuwe CIFS doet dus iets anders, na ca 1 uur opnemen. Het is slechts een vermoeden...

M'n linux kennis gaat niet zover dat ik daar dan ook achter kan komen, laat staan fixen.

Iemand een idee over dit probleem en hoe op te lossen?

Tot die tijd moet ik het dus doen met Gemini 2.0, aangezien ik bijna niets live op TV kijk en alles record. Want een film de eerste 60 minuten kijken en daarna alleen maar hikkend, wekt wat irritatie op.

Ik was erg blij met Gemini 3, maar dat moet ik dus helaas even laten liggen.

[Optimist]

Zoals Michel aangeeft kan je beter NFS gebruiken.

 

Overigens: het zou eventueel kunnen liggen aan samba settings. Ik had eens problemen met samba in combinatie met zeer grote bestanden. Na een bepaalde bestandsgrootte houdt het met SMB gewoon op. CIFS heeft die beperking echter niet, maar jouw omschrijving doet me er toch aan denken.

 

NFS levert in de praktijk minder belasting op voor je dreambox, dus is de moeite waard om te proberen.

 

Optimist

[Gast]

Citaat:

Welke versie van samba draai je ?
Zet uitgebreid loggen aan in samba.
/etc/samba/smb.conf
log level = 10

Kijk wat de meldingen zijn.

Ik doe hetzelfde bij mij op LT en Ronald (meest recente) zonder problemen.

Samba versie: 3.0.10-1.4E.12.2
Log level reeds verhoogd en bekeken, geen nuttige info uit verkregen.
Daarbij; het werkt wel goed met gemini 2 en niet met 3. Ik zie niet meer waarom het alsnog met samba te maken heeft.

Citaat:

Zoals Michel aangeeft kan je beter NFS gebruiken.
Overigens: het zou eventueel kunnen liggen aan samba settings. Ik had eens problemen met samba in combinatie met zeer grote bestanden. Na een bepaalde bestandsgrootte houdt het met SMB gewoon op. CIFS heeft die beperking echter niet, maar jouw omschrijving doet me er toch aan denken.

NFS levert in de praktijk minder belasting op voor je dreambox, dus is de moeite waard om te proberen.

Optimist

Ik kan WEL grote bestanden kopieeren zonder een enkel probleem (4GB geprobeerd, zie TS).
Enkel het opnemen gaat mis in Gemini 3/LT Image.

Ik ga niet naar NFS; CIFS is een prima manier om te connecten naar een samba share, word op veel plekken zonder problemen gebruikt en heeft zich bij mij en andere DM7025 gebruikers allang bewezen. Alleen nu werkt het niet meer goed en ik wil weten waarom en het oplossen.

Ondertussen een stapje verder samen met de geweldigste collega allertijden:
Met modinfo de versies achterhaald:
Gemini 2.0 - CIFS 1.45
LT Image - CIFS 1.35 (second maneuver update 3 (20070803))
Wellicht is het aannemelijk dat in Gemini 3.0 ook CIFS 1.35 zit.

Een lagere CIFS versie dan Gemini 2.0 -- verassend...
(zie CIFS changes hier: http://fxr.watson.org/fxr/source/fs/cifs/CHANGES?v=linux-2.6 staan best relevante dingen over)

Momenteel loopt er een test bij een collega met LT-Image en ongeveer dezelfde setup. Hij heeft het probleem nog niet gezien, maar neemt dan ook nagenoeg niets op.
1. Eerst kijken of hij hetzelfde probleem krijgt na ca 1 uur opnemen.
2. CIFS module vervangen met versie 1.45 en nog eens kijken.
Word vervolgd...

[Gast]

Vervolg:

Momenteel loopt er een test bij een collega met LT-Image en ongeveer dezelfde setup. Hij heeft het probleem nog niet gezien, maar neemt dan ook nagenoeg niets op.

1. Eerst kijken of hij hetzelfde probleem krijgt na ca 1 uur opnemen. -- Kwam niet voor. Samba bleef rustig, ook nog na 3 uur opnemen.

2. CIFS module vervangen met versie 1.45 en nog eens kijken. -- niet geprobeerd aangezien dat geen zin heeft.

 

Ben nu bij mij aan het testen:

Gemini 2.0 met CIFS 1.35 (de oudere dus), kijken of hetzelfde probleem wat ik met Gemini 3.0 en LT Image heb dan voorkomt. (aangezien die met CIFS 1.35 zijn uitgerust).

Het antwoord weet ik over ca 1 uur. <img src="/forums/images/graemlins/mad.gif" alt="" />

Niet echt snel testen zo...

 

Edit:

resultaat: geen enkel probleem. samba blijft rustig kabbelen zoals hij dat ook doet bij CIFS 1.45.

[Gast]

Na veel geexperimenteer (waar zoals gezegd nogal wat tijd in zit omdat het probleem zich pas na bijna een uur ging uiten) en een korte vakantie heb ik tijd om de oplossing voor het hiervoor omschreven probleem even met jullie te delen.

 

Ja, je leest het goed. DM7025 + LT Image HAD een probleem.

 

Veel testen gedaan, ik zal ze niet allemaal beschrijven.

Deze wel:

Test gedaan met LT-Image + cifs.ko (versie 1.35) -> probleem bestaat

Test gedaan met LT-Image + cifs.ko (versie 1.45) -> probleem bestaat

(Oorspronkelijk zit cifs 1.35 in het LT Image en Gemini 3 image, terwijl in gemini 2.0 cifs 1.45 zit!)

Dus het lag niet aan de cifs versie alleen.

 

Mount options aangepast, 'direct' toegevoegd.

Citaat:

http://linux.die.net/man/8/mount.cifs

directio:

Do not do inode data caching on files opened on this mount. This precludes mmaping files on this mount. In some cases with fast networks and little or no caching benefits on the client (e.g. when the application is doing large sequential reads bigger than page size without rereading the same data) this can provide better performance than the default behavior which caches reads (readahead) and writes (writebehind) through the local Linux client pagecache if oplock (caching token) is granted and held. Note that direct allows write operations larger than page size to be sent to the server. On some kernels this requires the cifs.ko module to be built with the CIFS_EXPERIMENTAL configure option.

Test gedaan met LT-Image + cifs.ko (versie 1.35) -> probleem bestaat

Test gedaan met LT-Image + cifs.ko (versie 1.45) -> probleem bestaat niet meer

 

Deze config loopt nu bijna 2 weken zonder een enkel probleem met mijn opnames. Mijn samba server blijft rustig. Ook bij meer dan 5 opnames gelijkertijd + 1 afspelen. (en ook na meer dan 1 uur van dit).

 

Om andere 'gelukkigen' die dit probleem ook hebben een beetje op weg te helpen staat hier de cifs.ko (versie 1.45 -> uit gemini 2.0)

Of in de bijlage van dit bericht. (zip)

 

Zet deze file in \lib\modules\2.6.12.6\kernel\fs\cifs

 

Vergeet daarna je mount options niet aan te passen in de automount.sh:

(voorbeeld Let op de 'direct'!)

#!/bin/sh

mount -t cifs //291.65.14.888/share /automount/hdd -o rw,direct,rsize=16384,wsize=16384,user=dreambox,password=verysecret

 

En vergeet niet te rebooten.

Hoe dan ook, ik heb niemand gesproken/gezien/gelezen die ditzelfde probleem heeft ervaren. Dat is nog het raarste van alles. Maar het is opgelost. Gelukkig.

1420484-cifs.zip

[wian]

Goed werk. Ik probeer nu ook op te nemen via het netwerk met Gemini 3.0, maar ik krijg telkens de melding dat er geen harddisk inzit. Heb de netwerkshare gemount op /automount/cifs, /automount/hdd en /media/hdd (toen liep ie vast). Waar moet je de netwerkshare mounten om op te kunnen nemen?

[Gast]

Mounten op /automount/hdd

en een symlink daarnaar maken op /media/hdd en /hdd

[wian]

@remco_k: Werkt als een zonnetje. <img src="/forums/images/graemlins/xyxthumbs.gif" alt="" />

 

Dit heb ik gedaan:

 

cifs mount aangemaakt met automounter

 

onder /automount/cifs is de samba share gemount

 

Symlink gemaakt van /hdd/movie naar /automount/cifs/movie.

 

[Gast]

Nou na een maand de hierboven beschreven CIFS versie (1.45) te hebben gebruikt, heb ik toch nog af en toe het hikken probleem gehad tijdens het opnemen.

Eerst dacht ik nog dat m'n DB zelf de CIFS versie had vervangen voor het orgineel (de oudere 1.35 dus) maar dat bleek na controle niet zo.

 

Toen mijn opname van de Lama's van afgelopen vrijdag vol met hikken zat was ik het ZAT! (Dus moet ik de herhaling van vanavond maar opnemen <img src="/forums/images/graemlins/grin.gif" alt="" />)

Nu mount ik met NFS naar m'n server, getest met 5 opnames gelijkertijd over 1,5 uur terwijl ik er 1 zat te kijken. Deze test 2x uitgevoerd.

Geen CPU load op m'n server, alleen wat IO waiting. (wat logisch is).

Het lijkt dus op te zijn gelost, maar dat dacht ik anderhalve maand geleden ook.

Voordeel van deze oplossing is dat ik geen relatief smerig truukje uit hoef te halen met de cifs module, wat in toekomstige images misschien tot problemen zou kunnen leiden.

 

Mijn advies voor als je ooit met hetzelfde probleem zit: neem het advies van andere forumleden ter harte en ga over op NFS...

(Hoewel ik nog steeds vind dat CIFS ook prima moet werken, en dat doet het ook op Gemini 2.0). Ik blijf het raar vinden.