24 replies to this topic

[julion]

Ik heb 2 ontvangers. Een VU+ Duo2 en een VU+ Duo die ik als partnerbox gebruik.

Sinds de update van 19-02-2017 slaat de  VU+ Duo2 zijn opnames op op de harde schijf van de VU+ Duo.

 

[littlesat]

Sinds de update van 19-02-2017 slaat de  VU+ Duo2 zijn opnames op op de harde schijf van de VU+ Duo.

Dan staat dat blijkbaar zo ingesteld....

[julion]

Nadat ik een image, van 7-2-2017, terug heb gezet op mijn Duo2 nam hij weer op de interne schijf op.

Bij de opnamelocatie, van het image van 7-2-2017, staat de standaard opnamelokatie op /hdd/movie.

Bij de opnamelocatie, van het image van 9-2-2017, staat de standaard opnamelokatie op standaard opnamelocatie.

Ik heb deze veranderd naar /hdd/movie en nu werkt het weer goed.

[MiLo]

De "standaard opnamelokatie" is, in volgorde van prioriteit:
-1- Waar een "/hdd" link naar wijst
-2- Wat als /media/hdd gemount is
-3- De grootste lokale disk (kan ook USB, esata e.d. zijn dus)
-4- "Iets anders" dat gemount is

Verschil met voorheen is dat dit nu pas bepaald wordt zodra een opname start (en dus niet meer bij het opstarten).

Waarschijnlijk heb je ooit "gebruik als harddisk vervanging" aangevinkt voor de share, waardoor regel -1- in werking trad?

[Bram55]

Nee hoor, TS heeft gelijk. Ook hier werden opnames plots op de NAS weggeschreven ipv de interne HDD. Even de opname locatie opnieuw instellen en alles draait weer.

Gewoon een klein foutje in de image. Het zou jullie sieren als jullie dit zouden toegeven ipv het op de gebruiker af te schuiven.

[MiLo]

Nee hoor, TS heeft gelijk. Ook hier werden opnames plots op de NAS weggeschreven ipv de interne HDD. Even de opname locatie opnieuw instellen en alles draait weer.

 

Klinkt als bug, hij hoort voorrang te geven aan een lokale disk.

 

Hoe is je NAS gemount? ("cat /proc/mounts" levert alles wat ik weten wil)

[MiLo]

Gewoon een klein foutje in de image. Het zou jullie sieren als jullie dit zouden toegeven ipv het op de gebruiker af te schuiven.

 

Ik schuif niks af, ik vertaal alleen wat hier in code staat:

https://github.com/O...ctories.py#L108

[WanWizard]

Begrijp ik uit deze code goed dat we nu ook definitief afstappen van de "movie" folder? L#135 en verder lijkt me de fallback voor bestaande situaties.

[HPPli]

Begrijp ik uit deze code goed dat we nu ook definitief afstappen van de "movie" folder? L#135 en verder lijkt me de fallback voor bestaande situaties.

Jullie praten "langs elkaar heen" en komen met veronderstellingen !

 

Feit is dat sinds jullie de door gebruiker ingestelde opname locatie(s)-regels hebben veranderd naar een default waarde bij//na een start (dus, <standaard opnamelocatie> wordt deze nu pas bij opname nader bepaald middels;

 

  def defaultRecordingLocation(candidate=None):   if candidate and os.path.exists(candidate):   return candidate   # First, try whatever /hdd points to, or /media/hdd   try:   path = os.readlink('/hdd')   except:   path = '/media/hdd'   if not os.path.exists(path):   path = ''   # Find the largest local disk

 

Zoals inmiddels ervaren gaat nu de "zoektocht" naar een opname-locatie op een andere manier en worden de eerdere (oude) instellingen ofwel de opgegeven opname-locatie(s) genegeerd.

 

Conclusie: prima mod maar niet getest ! Beter was een waarschuwing geven dat de opnamelocaties opnieuw moeten worden aangegeven/ingesteld i.p.v. om de "brei" te draaien !

[MiLo]

Begrijp ik uit deze code goed dat we nu ook definitief afstappen van de "movie" folder? L#135 en verder lijkt me de fallback voor bestaande situaties.

 

Nee, *deze* code is al heel oud.

 

De bedoeling is altijd geweest dat pas bij aanvang van een opname deze routine werd aangeroepen, maar dat gebeurde uiteindelijk niet. Verder was het niet mogelijk om, eenmaal van de default afgeweken, deze weer terug te zetten. Da's pas opgelost.

Wie een disk in de box "geschroefd" heeft, zou geen verschil moeten merken, want dat is altijd al de default geweest.

Wie (USB) disks aansluit terwijl de box aanstaat, zou moeten merken dat de box voor de grootste disk kiest, in plaats van wat er toevallig in zat bij opstarten.

Wie ooit zelf een andere lokatie gekozen heeft (via het opnamelokatie menu, dan wel via symlinks) merkt geen verschil, want van de ingestelde waarde wordt niet afgeweken, die blijft staan.

 

Als dit niet zo is, zoas bij jullion en bram55 blijkbaar gebeurde, dan is dat blijkbaar nog een bug in de code, die ik alleen kan oplossen met hun hulp.

Edited by MiLo, 22 February 2017 - 14:27.

[WanWizard]

@HPPli,

 

Helemaal niet.

 

defaultRecordingLocation() krijgt als parameter de ingestelde locatie mee, en de eerste "if" in de method checked of dat zo is, en of die bestaat. En zo ja, dan wordt die gewoon gebruikt.

 

Dat staat helemaal los van mijn opmerking, die niets te maken heeft met het probleem van de TS, dat was een vraag aan MiLo inzake deze implementatie.

 

Dus jij moet niet zo snel met veronderstellingen komen.

[HPPli]

@HPPli,

 

Helemaal niet.

 

defaultRecordingLocation() krijgt als parameter de ingestelde locatie mee, en de eerste "if" in de method checked of dat zo is, en of die bestaat. En zo ja, dan wordt die gewoon gebruikt.

 

Dat staat helemaal los van mijn opmerking, die niets te maken heeft met het probleem van de TS, dat was een vraag aan MiLo inzake deze implementatie.

 

Dus jij moet niet zo snel met veronderstellingen komen.

 

Oh, oh wat zuur weer.   Laten we maar weer snel on-topic gaan

 

Bij mij waren ook alle "oude" instellingen bij diverse STB's gewoonweg terug gezet naar de <standaard opnamelocatie> regel.

Nadat ik alles weer had teruggezet naar bijv  " /hdd/movie/ "  zoals deze instellingen voorheen stonden werkt alles weer als vanouds.

De "oude" instellingen in automounts.xml voor opnames richting NAS of andere extern HDD's blijven gelukkig onveranderd. Het is enkel de opname-locatie die roet in het eten gooit. 

[WanWizard]

Dat lijkt me inderdaad niet in de haak, maar ik zie niet direct waar deze wijziging voor een veranderde setting elders zou moeten zorgen. Maar daar mag MiLo zich dan weer druk over maken.

[_HarmeN]

Hier was ook de standaard locatie ipv /hdd/movie weer standaard locatie...

[WanWizard]

Wellicht is deze change de boosdoener: https://github.com/O...f79f6eef93fL110

[Bram55]

Ik heb enkele weken geleden problemen gehad met mijn interne HDD. Omdat ik enkele timers had gepland, heb ik toen daarvan even de opname locatie gewijzigd naar de NAS.
Toen de problemen met die interne HDD waren opgelost heb ik de opname locatie weer teruggezet naar hdd/movie. Na de update schreef ie toch weer weg op die NAS locatie.
Ik ben toen naar instellingen > systeem > opname locatie gegaan en daar stond nog gewoon hdd/movie. Ik heb dit opnieuw bevestigd dmv de groene knop en het probleem was opgelost.

@Milo, hoop dat dit voldoende info is.

[HPPli]

Wellicht is deze change de boosdoener: https://github.com/O...f79f6eef93fL110

Klopt, over deze mod van @Milo zo'n 4 dagen terug schreef ik eerder vandaag;
"Conclusie: prima mod maar niet getest ! Beter was een waarschuwing geven dat de opnamelocaties opnieuw moeten worden aangegeven/ingesteld i.p.v. om de "brei" te draaien !"

[cobus]

Idd hier stond hij ook op standaard opnamelocatie terwijl ik gewoon een hdd erin heb zitten (et10k).

[WanWizard]

Dat zou op zich niet uit moeten maken, want volgens de logica komt hij dan automatisch nog steeds bij /media/hdd uit. Dus dat is op zich helemaal geen probleem.

 

Het is alleen een probleem als hij spontaan ergens anders is beginnen opnemen dan voor deze aanpassing, die cases willen we graag weten.

[cobus]

Oh sorry heb ik het verkeerd begrepen.