Jump to content


Member Since 8 Nov 2009
Offline Last Active 26 Apr 2021 07:26

Posts I've Made

In Topic: Wat geeft het beste beeld

23 December 2020 - 11:44

Alle streamingdiensten gebruiken de nieuwe H.265 codec waarmee 60% efficiënter wordt gestreamd dan de klassieke H.264 codec.

Marketing geleuter dat gebaseerd is op wat in vage theoretische gevallen wel misschien mogelijk zou kunnen zijn.

Wat in de praktijk gebeurt is dat men er klakkeloos vanuit gaat dat die factor klopt, en dus de bandbreedte per zender ook met 60% terug wordt gebracht. Want dat zou immers dezelfde kwaliteit leveren. In de praktijk worden deze theoretische maxima nooit gehaald, en dus ga je er in kwaliteit eigenlijk alleen maar op achteruit als er weer een nieuwe codec komt.

In Topic: Wat geeft het beste beeld

21 December 2020 - 15:53

Het maakt niet echt uit wie de upscaling doet, wat er nooit is geweest is kan er toch niet bijgemaakt worden... Speciaal een 4k ontvanger kopen heeft nu nog weinig nut aangezien er, zoals je al concludeerde, eigenlijk geen zenderaanbod is.

In Topic: Memory leak in MovieList.py

12 December 2020 - 17:29

Usually the best way to break a self-ref chain is to have a third level, e.g. typically with subscriptions:


a.parent = b



Now there's a cyclic dependency. But 'a' must store 'b' to be able to unsubscribe.

One way to solve:

a.parent = b.subscriptions


This way, a doesn't increase the refcount to b, and a can still unsubscribe when it goes out of scope.



In this particular case though, it's not as easy to break. A weak ref would help yes. Another thing might be to call self.l.setBuildFunc(...) only when needed, and set it back to None again when not building a list (in the load() function maybe?)


(I'm not a big fan of weakref, but in this case, it's the lesser evil compared to keeping that cylic dependency in. Probably the issue here is the refcounting done in the C++ part, which does not have a garbage-collector or any other way to detect cyclic dependencies)

In Topic: Memory leak in MovieList.py

12 December 2020 - 13:56

MovieList is a GUI thingy, so that might make it behave strange when there's no actual GUI to display. Probably deleting that "list" object makes it release things a bit earlier.


The "del movielist" at the end is a no-op, it doesn't actually do anything. The method ends there, so all variables go out of scope there anyway and the whole local namespace gets deleted there anyway.


"del someobject" does not call the objects destructor, it just removes the local reference "someobject" from the namespace. It will call the destructor then if this happens to be the last reference to it.


(Example: a=[1,2]; b=a; del a; This will delete "a" but not delete the actual array since b still has a reference to it)



Usually objects not getting freed when you expect it are a result of cyclic references. In Python, the garbage collector will find and destroy such objects. but it's hard to predict when that will run. Sometimes, something is keeping a reference alive. Tricky to find.

In Topic: Memory leak in MovieList.py

6 December 2020 - 09:33

Since MovieList is all Python code, memory "leak" can only be caused by some client keeping a reference to some object alive.


I'm unfamiliar with the webinterface, I lost track of how it works long ago.


It would be really heplful to know which call is causing it.