Erik Slagter

I tested, but i am stuck in missing download dependencies, too many lately, nobody test them? Or homebuilds are not so important

That has always been an issue and will remain so. The reason is that most sources are only fetched once. Our build servers have almost all packages downloaded at some time or another. So a source can be unavailable for sometimes years and we won't notice.

Also for various "git autorev" sources (which need to be updated on every build), we maintain a local git repo cache on the build servers. If you need to do a frequent build, you may want to consider implementing something similar. It's not very complex.

It's not like we don't care.

The most interesting challenge is to emulate the (platform) hardware, not the processor. On i386 there is memory and io virtualisation, the ARM and MIPS processors in our STB's don't have it. That means every call to an I/O address (we're talking Z80 here...) or a memory address needs to be detected and then the respective action of the hardware needs to be emulated. If you don't have virtualisation it means every instruction needs to be (partly) decoded and checked for every possible address. For load-and-store and load-execute-store instructions (which the Z80 has both of) it's extra complex, especially if both source and destination addresses have additional effects. What makes it even more interesting is that I/O adresses are only partly decoded and some ranges of memory too. That means that if you write to address x and read from address x + (memory window), you should see the same value. It's even more interesting, in that three versions of the ZX Spectrum exist, which are not completely the same on hardware level. There is no problem if you only use BASIC, of course, but once you start doing direct I/O access, you may see different behaviour. Some programs depended on that behaviour 

The Sinclair QL (the successor) was even worse in this respect, much worse even, many different version with quite some changes in both hardware and software. But there it wasn't a problem because all hardware was abstracted in the operating system. There was even a collection of library functions in ROM that where vector-indexed, so it didn't matter what hardware or firmware version you were using.

Yes I understand the "alignment" issue, but is insignificant compared to the other arguments (I think you agree).

I think the point Littlesat is trying to make that compared to C, in Python the delimiter is a syntactical element, the amount of white space has implications on the way the input is interpreted. Which I think is one of the weakest points of Python anyway. Python uses all sorts of heuristics to determine whether indentation has increased, decreased or remained the same from the previous line, very ugly. One more reason to stick to tabs, where one tab is exactly one level of indent, no misinterpretation possible. 

I really don't understand the arguments of the pro-space folks.

Shorter is not a valid argument (as Wanwizard already explained).

My main issue with spaces is that a given random point in a random file, seeing an indent of 12 spaces, does that mean the indent level is 3 spaces by 4 levels or 4 spaces by 3 levels etc. Using tabs one level is always one character.

There are a number of other issues with spaces (like having to backspace over all of them when going back one level) but they are more or less workaroundable. Also using tabs one can configure the shift width themselves, some of use prefer a small shift width, others like a wider shift width. Using tabs, that is never an issue, your not forced to use the same as someone else.

Mostly in Python but also in the C++ code, in enigma2 the "de facto standard" has always been to use tabs as delimiters. Sometimes "space" die-hards added patches that introduced spaces, but most of these we already converted to "the right thing". If there are still places where tabs and spaces are mixed (evil!) they are only a handful and we need to clean them up too.

I don't care whether the whole world is misguided and does not understand the meaning of a delimiter in a computer program and really that it does not matter whether it indents 4 of 8 positions and really that you can set the tab width in your favourite editor yourself! And apparently most of the enigma2 developers agreed with me.

EDIT: this is the one and only occasion where Schimmelreiter and I agree.

BTW this "kernel" module is the drivers. An opaque blob of binary code made by the manufacturer. It is NOT code from the kernel itself.

Het lijkt wel of er twee PID's zijn DVB subs en dat die op enig moment zomaar gewisseld worden? Ik zie dat op zich vaker, een track met "SD" en een track met "HD" subs. Kun je dat checken? Ik vind die kleine wel mooi eigenlijk

As mentioned in the internal topic: I did a quick google on the subject and I found a lot of topics about VU+ not being able to play VC-1 (on several images). So I don't think it's a gstreamer issue, it's simply removed from driver support, apparently.

As betacentauri already mentions, either buy a real media player, or, which in my opinion is a good alternative, re-encode to a current DVB codec like h264 or h265 (I do that often).

It seems like VC-1 isn't much used nowadays anyway. Apparently the closed posture of Microsoft in this area has turned the market against them. Serves them right!

"xvid" = "divx" = "mpeg 4 asp" = actually mpeg 4 video codec (as opposed to mpeg 4 advanced video codec = h264).

The dm800 already didn't support mpeg4 vc. Mpeg4 vc is a disaster (according to the DVB guys...), it's an "improved" version of mpeg2, but the improvements are marginal and it also imposes all sorts of limitations. That's why DVB never adopted it. And nowadays it's also very obsoleted (released end 1990's, and it already has TWO successors).

So I think it can be very well defended that support for mpeg 4 vc is dropped. Mpeg2 is still supported as it's still part of DVB, which mpeg4 vc isn't.

On the other hand, VC-1 is still actual. It was meant to be a competitor to h264 from Microsoft, but never got really foothold. But it's still actual. But also it has never been part of DVB so manufacturers are free to not implement support.

IIRC there are known issues with VC1 on VU+. I have reported it some time ago.

This is quite usual for settopboxes. They generally have blindscan capable tuners but the manufacturer needs to supply a supporting binary and they often don't. That is, as said, not specific to Maxytec.

If you're going to want to do blindscan (and several other features as well), don't rely on the sale flyer, ask other buyers.

The issue has been reported.

Geef mij maar apparaten die totaal dom en netwerk-agnostisch zijn (i.e. géén netwerkaansluiting). Die maak ik dan zelf wel, mezelf vertrouw ik meestal wel 

It's so-called "in band metadata". In these days video was analog and there was no way to supply additional metadata (like timecodes from the camera) besides the video, but remaining in sync. So they simply put the data IN the video ("in band"). As television sets usualy had quite a large overscan area, you were supposed not to be able to see the data.

Besides that, analog video recorders were not able to record the complete picture (including the "overscan" areas) so they would produce noise in those area's (due to limited bandwidth and heads on the drum that needed to switch between each field).