196 replies to this topic

[Rob van der Does]

Vraag me niet naar hoe e.e.a. is geïmplementeerd, maar in ViX is er

1- een timeout op het proberen een mount te vinden,

2- een 'mount again' toets en

3- een 'auto remount', instelbaar op elke x uur.

 

Deze werken zowel op een NFS- als op een Samba-mount.

 

De reden is precies het hierboven aangehaalde probleem: niet alle mounts zullen per definitie beschikbaar zijn op het moment dat een box boot.

 

Een mooie toevoeging zou nog zijn een 'auto remount' op het moment dat een mount wordt aangesproken maar niet antwoordt en het verzenden van een WOL-package enige tijd later gevolgd door een mount again.

Edited by SatKiekerd, 14 September 2013 - 11:07.

[nietgiftig]

Maar nogmaals, als het alleen om het mounten gaat, dan is het op zich nog wel op te lossen.

 

Na de duidelijke beschrijvingen (hulde!) begrijp ik dat het niet om het mounten gaat, dat is inderdaad al wel gelukt

 

Maar dan, het is je gelukt om je NAS te mounten. De NAS is in slaapstand gegaan en is dus niet meer bereikbaar. Enigma doet iets waardoor een block van de remote disk nodig is. Wat dan? Het operating system kan niet beoordelen of de applicatie ermee om kan gaan dat er een leesfout (of zelfs schrijf-fout) wordt gegeven. En blijft daarom maar eindeloos wachten tot het NAS alsnog reageert. In de tussentijd staat de betreffende thread in enigma compleet stil. Sterker nog, je kunt enigma op z'n moment vaak niet eens killen (ook niet met kill -9, process "D" state = niet killen).

 

Voor mij persoonlijk is het grootste probleem niet het opnemen, maar het afspelen.

Na het drukken op de filelist weet je na 10 seconden al van "dit gaat mis"

Het zou al mooi zijn als je de thread die dan gestart is handmatig kunt afbreken zodat je niet je PC aan hoeft te zetten om de box netjes te laten inslapen en weer wakker te maken.

 

Of misschien een mogelijkheid om het "onthouden" van de laatste directory waar je geweest bent (je onbereikbare NAS) na een ping ongedaan te maken en naar een interne default movie dir te gaan.

Ik begrijp dat je hier alleen maar wat aan hebt als je ook een interne drive hebt, maar je kan de box dan wel zonder een externe pc tot orde roepen.

 

 

[Erik Slagter]

Vraag me niet naar hoe e.e.a. is geïmplementeerd, maar in ViX is er

1- een timeout op het proberen een mount te vinden,

2- een 'mount again' toets en

3- een 'auto remount', instelbaar op elke x uur.

 

Deze werken zowel op een NFS- als op een Samba-mount.

 

De reden is precies het hierboven aangehaalde probleem: niet alle mounts zullen per definitie beschikbaar zijn op het moment dat een box boot.

 

Een mooie toevoeging zou nog zijn een 'auto remount' op het moment dat een mount wordt aangesproken maar niet antwoordt en het verzenden van een WOL-package enige tijd later gevolgd door een mount again.

Dan zul je op z'n minst ook ervoor moeten zorgen dat er geen opnames gemaakt worden zolang er niet gemount is. Niemand zit te wachten op een volgelopen flash van een opname. Maar ik zie nog wel een paar problemen.

 

Bij NFS bijvoorbeeld zal een mount inderdaad meteen terugkomen als de server er niet is. Maar als er al gemount is en de server dán onbereikbaar raakt, dan is het einde zoek.

Edited by Erik Slagter, 14 September 2013 - 11:13.

[littlesat]

Uiteraard kan je in python allemaal trap, schop en brute force techniekjes toevoegen om een mount te remounten, als dit niet lukt het om het uur of zo iets nogmaals te proberen en als het on demand niet lukt dan maar via een shortcut.

Maar het begint uiteraard met de boel op je netwerk goed in te regelen. In feite zal een NAS altijd gevonden moeten worden en hoor je die trap, schop en brute techniekjes eigenlijk niet nodig te hebben.

 

En dan nog met die trap, schop en brute force techniekjes kan een opname simpelweg gewoon zonder enige waarschuwing mislukken....., een flash volschrijven enz...

Edited by littlesat, 14 September 2013 - 11:19.

[Erik Slagter]

Na het drukken op de filelist weet je na 10 seconden al van "dit gaat mis"
Het zou al mooi zijn als je de thread die dan gestart is handmatig kunt afbreken zodat je niet je PC aan hoeft te zetten om de box netjes te laten inslapen en weer wakker te maken.

Tsja en dat kan dus niet.

Dit is een probleem dat autofs in theorie zou oplossen. De share zou enige tijd niet gebruikt worden, dan wordt die geumount. Je spreekt 'm weer aan, er wordt weer gemount en dat mislukt dan, foutmelding. Maar niet hangen. Het gaat fout omdat de server onbereikbaar raakt terwijl de share nog gemount is.

Alleen zoals eerder gezegd, werkt het in de praktijk niet ideaal.

[Erik Slagter]

Uiteraard kan je in python allemaal trap en schop techniekjes toevoegen om een mount te remounten, als dit niet lukt het om het uur of zo iets nogmaals te proberen en als het on demand niet lukt dan maar via een shortcut.
Maar het begint uiteraard met de boel op je netwerk goed in te regelen. In feite zal een NAS altijd gevonden moeten worden en hoor je die trap en schop techniekjes eigenlijk niet nodig te hebben.

Het is symptoombestrijding en kan daardoor ook gewoon niet altijd goed werken.

De enige echte oplossing is binnen de linux kernel, maar dat gaat niet gebeuren natuurlijk. Uitbreiding van het SMB/CIFS en NFS filesystem met het sturen van een WOL-packet na de eerste timeout, dat zou de enige echte oplossing zijn.

Voor de rest ben ik heel nedering van mening dat als je een NAS hebt, dat je die daar hebt staan om bestanden te serveren en clients rekenen daar op. Het is er allemaal niet opgemaakt dat je je NAS zomaar uitzet. Wie weet komt daar ooit nog wel eens wat voor, maar dat zal niet in enigma zijn.

[littlesat]

Tsja en dat kan dus niet.

Zou je niet voordat je gaat kijken ff kijken of de directory bestaat? (/media/net....) en bestaat die niet dan weet je dat de mount er niet is, zodat je snel(ler) een goede aktie kunt ondernemen... Het is maar een idee... Of bestaat die map dan gewoon en kom je er later achter???

[littlesat]

Het is er allemaal niet opgemaakt dat je je NAS zomaar uitzet.

Een dacht dat je een NAS juist had zodat die altijd aan stond.... (behalve bij stroomuitval uiteraard).

[Erik Slagter]

Dat is nog weer een extra probleem. Het mountpoint blijft gewoon bestaan. Je zou dus op z'n minst moeten checken of er iets op gemount is. Dat kan ook wel, maar de procedure die je daarvoor moet gebruiken spreekt ook de share aan, waardoor enigma net zo hard weer hangt als de server niet antwoord.

Je kunt principieel niet checken of de server van een share antwoordt zonder het risico zelf vast te komen zitten.

[Erik Slagter]

Het is er allemaal niet opgemaakt dat je je NAS zomaar uitzet.

Een dacht dat je een NAS juist had zodat die altijd aan stond.... (behalve bij stroomuitval uiteraard).

Ja dat dacht ik ook

 

Die nasjes voor thuis verbruiken bijna niks. Die op m'n werk hebben meer dan 1 x 16 A groep nodig

[Rob van der Does]

Het gaat niet alleen om een NAS (hoewel die hier meestal ook helemaal uit staat (simpelweg omdat die zelden wordt gebruikt), maar ook om andere lokaties (zoals een DVD-speler in een laptop/PC en de HDD van een andere box).

 

Ik ben het met je eens dat het technisch gezien het eenvoudigste is ervoor te zorgen dat een probleem zich nooit voor doet. Maar ja: de techniek is er voor mij, niet andersom.

Edited by SatKiekerd, 14 September 2013 - 11:27.

[Erik Slagter]

De techniek loopt nou eenmaal vaak achter op de wensen van de gebruiker. Om dit goed op te lossen zouden wijzingen in de linux kernel nodig zijn. De techneuten die daar aan werken, hebben helemaal geen boodschap aan een NAS die je uitzet, die zien dat vanuit een heel andere hoek. Je zou het natuurlijk altijd kunnen proberen, als feature request van bijv. het SMB/CIFS filesystem.

[littlesat]

Mounten met een PC is zo wie zo onverstandig en vraagt om problemen... Want een PC wordt normaal gespoken ook regelmatig uitgezet... Het is daarom verstandig om films die je wilt afspelen met je Enigma2 box dan ook ff kopieert naar de NAS of naar de interne harde schijf van je Enigma2 box. Dan voorkom je ook allerlei mount problemen ...

 

Ik denk dat je de "oplossing" beter hierin kunt zoeken... Kortweg niet mounten met een PC, maar ff de boel overzetten... Dan hoef je ook niet aan symptoombestrijding te doen

 

Tegenwoordig heb je een DVD of MKV binnen 5-10 minuten overgezet via het netwerk... en tijdens het overzetten kun je gewoon al kijken...

[Erik Slagter]

Tegenwoordig heb je een DVD of MKV binnen 5-10 minuten overgezet via het netwerk... en tijdens het overzetten kun je gewoon al kijken...

Als het een transport stream is wel, anders meestal niet.

 

Maar verder wel een goed idee ja. Je zet er een 1 Gb 2.5" disk in, lekker zuinig, stil en koel en die gebruik je dan als cache. Mijn linux server staat altijd aan, dus dat is geen issue zowiezo.

[MiLo]

Het zou toch wel fijn zijn, als de box na , zeg 10 seconden (instelbaar??) zou zeggen, kan de mount niet vinden, ik ga maar even naar de standaard interne drive, of bijvoorbeeld een mount again uitvoert voor degene die geen interne drive hebben.

Ik heb wel eens zitten rommelen met "de default opname lokatie is de grootste lokale disk of anders de eerste de beste mount waar ik kan schrijven". Dat leverde best een puinhoop op, niet normaal waar die "/media/hdd" allemaal terugkomt.

[Stephan296]

Dat is toch niet handig elke dvd of mkv over te zetten naar de box.
Zeker niet met die trage verbindingen naar de box aangezien die box nou eenmaal niet snel is haha.
Ik ga me maar eens verdiepen in autofs heb het eerder aan de praat gehad alleen toen ging enigma over de zeik haha.

Edited by Stephan296, 14 September 2013 - 13:23.

[Erik Slagter]

Ik heb wel eens zitten rommelen met "de default opname lokatie is de grootste lokale disk of anders de eerste de beste mount waar ik kan schrijven". Dat leverde best een puinhoop op, niet normaal waar die "/media/hdd" allemaal terugkomt.

Ook daar ga je het probleem niet mee oplossen, want op het moment dat je gaat kijken wat er achter dat mountpoint zit, en de server antwoord niet, dan staat je proces meteen in disk wait == hangen.

 

Met autofs kun je nog geluk hebben dat de share ge-umount is voordat de server plat/suspend gaat. Maar als door wat voor reden dan ook dat umounten niet meteen gebeurt voordat de server onbereikbaar is, heb je ook al weer een "hangpunt".

[littlesat]

Zeker niet met die trage verbindingen naar de box aangezien die box nou eenmaal niet snel is haha.

Met een ET9K heb ik een DVD overgezet binnen 5 minuten... snel zat lijkt me....

[Erik Slagter]

En als je die voor die tijd hebt omgezet naar een mkv met h264, dan halveert de omvang nog eens (bij dezelfde kwaliteit), scheelt ook weer een boel diskruimte.

[Pedro_Newbie]

Maar hoelang duurt dat omzetten naar een mkv met h264 dan? En welk programma kan je daar het beste voor gebruiken?

Edited by Pedro_Newbie, 14 September 2013 - 15:50.