Messages

Chris mentioned i while ago that a problem of adding more and more media-functionality on the mvp is the limited space in the dongle/on the mvp - is this still critical?

Sure, this is still a problem, the people from mvpmc are currently at the limit and have problems to add more features.

Yes, but they also have a huge functionality built into their software. For me they do much too much on the MVP.

They have a complete UPnP client. Also what I have seen so far is that they scale the pictures on the mvp (which I would avoid as stated above).
So they have lot's of libraries and are now facing the memory limits. Now they try to make it modular too as riban proposed.

I personally don't have the needs for a full UPnP client and all the other stuff they are doing - connecting to different kind of servers (mythtv, slimserver, flac, replaytv, etc.), having a VLC client built in, sshd support, ....
A simple way to display pictures and play sound directly from a VDR server is fine with me. I have no other media servers in my network and don't plan to do so.

A lean VOMP client with customized media functionality is enough for me. So in case we limit the functionality to customized VDR-Vomp-protocol, there should not be the same issue as mvpmc is having now.

But this is for sure only my requirement, others may also want these functionalities.

Hi avvdr,

yes, yes, yes.
How I would love to have this functionality already last Sunday, when my parents were visiting us and showing pictures of their last travel. This would have been a wow effect 

Anyway, because of lack of time (family and work), I couldn't jump into working on the same functionality. But from time to time I can spend time to think how to do it.
The issue I see, is that JPEGs (i.e. the one from the newest cameras) are getting bigger and bigger. Sooner or later these will become so big that the memory at the MVP is getting the limiting factore. It may crash or not display the picture. Wifes won't accept this 

So my idea would be to have the scaling as well as rotating on the server. This would have several benefits:
1. The memory in the MVP is no issue anymore, as the jpeg for the MVP is now already very small

2. Assuming the server is at least as fast as the MVP processor, the whole thing get's much faster, as at least the transfer through the network is then much faster. I assume everybody has a server at least as fast as the MVP. How to get tumbnails displayed on the MVP is horror I assume, just because of the network alone.

3. You could use the memory at the server for caching, let it be the thumbnail view or even the scaled pictures. If it is going to be perfect when it could even scale already the comming pictures, while you are currently watching on the MVP on.
Memory on the server is a no brainer for me, as it could use the hd as well for storing the thumbnails, etc.

4. You could easily integrate also EXIF information (i.e. rotation info). For sure you could do it on the MVP as well, but in case everygthing is on the server, the server could do it too.

I know this is against a idea of having everything done on the MVP, but for pictures I definetly see big advantages when we do the active part on the server.

Comments?

VDR version 1.4.6 is now available at

ftp://ftp.cadsoft.de/vdr/vdr-1.4.6.tar.bz2

A 'diff' against the previous version is available at

ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.5-1.4.6.diff

A 'diff' against the latest maintenance patch is available at

ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.5-2-1.4.6.diff

A summary of all the major changes since the last stable
version can be found at

http://www.cadsoft.de/vdr/download.htm

This version is binary compatible with the previous version,
so plugins don't need to be recompiled.

Thanks to the many people who have contributed in the making,
testing and debugging of this new version of VDR.

Have fun!

Klaus

I can for sure tell this painting bug is visible till I first used Vomp (for me at least since 0.2.3).
But I don't consider it a big issue.

Thx.

yes a reboot solved the issue.
But I'm sure I did a reboot already when 0.2.5 was released. So it seems to be an issue which could pop up sometimes.

When I get a clue under which circumstances this appears again, I will write again into this thread.

Hello,

I only have the assumption that currently the screen is always cut left and right. This I only get since 0.2.5.

What I can see is that the TV logo of the channels cannot be displayed completely, so there is missing something left and right.
Also the persons look a bit fat...

I tried to change the possible settings (TV aspect ratio and 16:9 on 4:3 display mode), but no effect on the screen.
I have a 16:9 and a 4:3 TV, and on both I can see this effect.

Does anybody else see this too?

Hello Chris,

thinking about how to include viewing photos, the question comes up how you would like to implement such a functionality (in case you would do it)?

As JPEGs can be huge (in comparision to the RAM size of the MVP), I assume that an "easy" opening of files via e.g. NFS or SMB may at the end crash the MVP. Also we would need to implement support for e.g. EXIF as well or other file types like PNG, BMP,.... Not thinking about how to provide fast thumbnail overviews.

On the other hand we have a server who could scale the photos to the PAL/NTSC size already before offering them through the network, which would be faster as network bandwith is one of the time consuming factors anyway. Also the server could store the thumbnails or the scaled photos in a cache.

The way how VDR plugin itself is doing it is somehow not feasable. VDR generates a video out of the photos. I assume this is only done because normal FF cards cannot display JPEGs. I don't think this makes much sense at all with a MVP as we could use the photos directly.

So I searched for a photo server who could do following things:
- Scale the photos to PAL/NTSC size
- Use EXIF information where possible
- Can provides thumbnails
- Can use BMPs, PNG, ...

At least I didn't find any special one, beside of all the UPNP servers. I didn't test the ones I found in order to see if they provide the above functionality (i.e. scaling to NTSC/PAL before offering the files).

The functionality described of the servers normally doesn't focus on the functionality of photos. At least in the documentation for the UPNP standard, all the needed functionality is included.

But in case you would go such a way, it would end up that we have a working implementation of UPNP which is bound to djmount, FUSE and therefore to the newer kernel version (2.4.31) - as MVPMC is doing it as well.

Or you would build a VDR plugin with somehow a "proprietary" implementation of UPNP functionality for photos.

Is this also your understanding and/or which way you would like to implement it?

VDR maintenance patch 1.4.3-4 is now available at

ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.3-4.diff

This is a 'diff' against version 1.4.3-3 (which is the official
version 1.4.3, patched with
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.3-1.diff,
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.3-2.diff and
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.4.3-3.diff).


Small fixes to the officially released VDR versions will be first
made available as "maintenance patches" in the Developer directory,
so that they can be reviewed and tested before a new official
release is published.

So please apply the above patch and report whether it works (or
if it causes any new problems).


This version is binary compatible with version 1.4.3-3, so
plugins need not be recompiled.


The changes since version 1.4.3-3:

- Fixed deleting EPG events that have a running status of "pausing" or higher.
- Fixed handling NITs with more than one delivery system descriptor tag for the
same transponder.

Have fun!

Klaus

This is very good news.

This also shows that there is a way to use the newer GCC version for building a working dongle. This would be very intersting as sooner or later no standard distribution will support the older GCC anymore (basically only Debian still does).

One question: Is it still the 2.4.x Kernel or already a newer one?

I did a similar question some months ago, so just check following answer http://www.loggytronic.com/forum/index.php?topic=120.0.

Not much but it helped me a lot.

@All:
As I haven't provided any code to Vomp yet, for sure it's not in my intention to give any advise to the original authors how to license their code. If any of the authors of Vomp feels offended by my proposal or wordings, please just say so and I will just shut up. I will accept this without any complain. In such a case please get already my excuse for my words written already.

@MartinR
winestreambase:
I also search for it and also didn't find any real inclusion in cvs. Maybe beside of the offered patch nothing went in. The last mail just included the bz2-patch http://www.winehq.com/hypermail/wine-patches/2005/08/0324.html. Maybe this helps you already in checking if the sources fulfill your needs. Anyway you may contact the author of this patch directly - he should have all detailed infos and may also help in technical details .

LGPL of pure Wine will not have any issues at all. LGPL can always be bound to GPL only programs. LGPL has not the "viral aspect" like the GPL, but it has a bit more restrictions to how you provide the source code than the GPL. The last difference is normally not a big issue, as if really something is missing in the distribution we can add it later on without a problem.

@All
If we have to use the way 2 anyway, my recommendation would be to keep the exception clause a bit general. We will not know what maybe needed on top in future versions and if the Windows changes the interface in e.g. Vista again. If we would be to explicit in the exception clause then the needed round for getting all feedbacks to change the clause needs to be done again and again. This would also help avoiding the problems with way 1 for the user and distributors and we could ship one complete binary.

So let's givew some explicit proposals:

Proposal 1:
The Vomp project hereby grants permission for linking against non-GPL libraries on Windows(R) platform to be used and distributed together with Vomp. This permission is above and beyond the permissions granted by the GPL licensei by which Vomp is covered. If you modify this code, you may extend this exception to your version of the code, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.

The last part is also needed, as it gives everybody the possibility to remove this clause again in future versions.
This version would involve mentioning the Windows platform, so it would not be possible to include in later versions a Mac version with similar issues.

This version is very general, it would also give the possibility for others to add a proprietary library in order to display e.g. Newsfeeds or whatever comes to mind as new functionality we would like to see implemented in FOS. So maybe it could be limited to:

Proposal 2:
The Vomp project hereby grants permission for linking against non-GPL video display and streaming libraries on Windows(R) platform to be used and distributed together with Vomp. This permission is above and beyond the permissions granted by the GPL licensei by which Vomp is covered. If you modify this code, you may extend this exception to your version of the code, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.

The most restrictive would be:

Proposal 3:
The Vcomp project hereby grants permission for linking against the non-GPL strmbase.lib library on Windows(R) platform to be used and distributed together with Vomp. This permission is above and beyond the permissions granted by the GPL licensei by which Vomp is covered. If you modify this code, you may extend this exception to your version of the code, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.

As stated in the beginning, I will not give advise to the authors what to do with their code. This I must leave for sure to the authors, i.e. Chris.

[not]

I think we have two possibilities:
1. Don't do any static linking to non GPL conform libraries at all. Also don't ship/offer any of the non-GPL conform libraries together with the GPL binary.
The GPL is only relevant for the case of distribution, not the development or usage. So if the developer only offers the binary with GPL only (or GPL conform) "data", then the GPL is not violated as everything you offered/distributed is in line with the GPL (and you offer the code/distribute for this part as well). If this then means for the user to link to non GPL conform libraries and the need to get the nonGPL conform libraries from somewhere else, it is the task of the user.
This should not be the preferred cases, i.e. if it involves for the user the need to get the needed libraries from somewhere else in case they are not part of the operating system.
Distributions and so on cannot give one simple package to install. So a lot of users will fail to install/use it.

This case is at least similar to the times when Qt was not free and KDE only distributed/offered their own libraries. The distribution of KDE and nonfree Qt was then done by others. Also the distributors said at the end their distribution is only mere aggregation so most of them included Qt and KDE. But this last point was controversial and therefore not all distributors followed this point (not talking about the ones simply denying every nonfree program). The real problem weren't KDE libraries itself, as they would have had the exception clause, but KDE used GPL only code/libraries from other projects w/o the exception clause granted.

Another similar example is the new way distributors do not include the nonfree graphic drivers anymore. They only provide the pure kernel and leave it to the user to get the non free part. Again, the user have no license issue, the license issue is only for the one who distributes. So the only one who may have an issue are the graphic driver companies, but this detail I leave to the lawyers. Graphic drivers are even more complicated as they share the same address room as the kernel.

While I was coding at KSpread, we had a library included which was not GPL conform (the chart engine). As KSpread and all libraries involved where LGPL only, it was not a big issue, but using this library was for me an issue as their restrictive license would have influenced the whole KSpread. My question to the core devs (David Faure) regarding this issue was simply answered by: As we do dlopen the library it is not in the same address room and therefore not part of the whole. Therefore the restrictive license was only valid for this component itself and this was then a minor issue.

2. Do the exception clause.
If you/all developers (and all statically linked libraries you use and are GPL only) add the exception clause, then it works as well.

I still don't fully understand how an added exception "wholly outside the GPL" to allow binaries distributed with non-free code can still comply with the GPL - the GPL attempts to give the end user the right to get the source code for all parts of their programs. With vomp for windows we could not do this. Any lawyers here??!

The definition how to license the code lies purely in the right/responsibility of the developer. If the developer wants something differently than the pure GPL, he has the full right to do so. If the user doesn't like these exceptions/changes, then the user still has the full right not to use the program provided. That's when it's called GPL with exception clause.
The GPL in this case reserves your right that any usage of your code must comply with the GPL (beside of the possible exception). For the user you grant the right that if he wants your code then he gets it - if you include an exception then you clearly state that the user doesn't have this right for the mentioned cases. So the GPL is valid for you code, but not for the whole program/binaries involved.

unless that component itself
accompanies the executable.

To me, that sounds like if any part of Windows / DirectX is statically linked in (themselves accompany the executable) then this exception cannot be used.
To this qoute, I'm not sure, if this is so strict, because in every windows program even the windows include files are included and also every compiler add statically linked startup code for the programms. If this is interpreted so strict, I don't think you can build a GPL programm on a non free compiler or OS. I think this is meant for the case, if GPL code is part of the OS, so that e.g. noone can turn linux in to a non free branch. But I'm not a lawyer, so may be I'm wrong.

Partly correct. Includes are in this view copyleft. I know for some cases in the include files there is also code which could be part of the license, but in most cases Includes only defines text with no implemented logic behind. Therefore they are "copyleft". Some companies see this differently but the common understanding of most is that Includes are copyleft.
Linkers/starting code are in this view rather part of the OS and doesn't fit to the GPL clause as well. They must be linked in but are provided by the OS.

But all other statically link libraries must comply to the GPL (or have the exception clause).

As most times: IANAL

But anyway, the way it should be done is to keep the GPL V2 and add an exceptional clause stating exactly what you want to do (something like "Binding to DIRECTX on Windows is allowed").
Exchanging GPL V2 with something else would also disturb me, as it involves the possibility to turn the full project into closed source (which is not what is needed AFAICS).
I don't speak native English and I'm not that into the detailed of what needs to be stated technically, but you should add here the term of what you want to add as exceptional clause.
Example for such an exception clause would be e.g. Gstreamer http://gstreamer.freedesktop.org/documentation/licensing.html:

The Muine project hereby grants permission for non-GPL compatible GStreamer plugins to be used and distributed together with GStreamer and Muine. This permission is above and beyond the permissions granted by the GPL licensei by which Muine is covered. If you modify this code, you may extend this exception to your version of the code, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.

How about "Jetzt".
If it is about the timer then "Jetzt" which translates to "now" in english would fit as well. No?

Chris, wouldn't then be "now" more accurate anyway as you use it here for explaining the text too?

Just want to add my priorities:

Out of the list of Schnurps:
1. (but the search string is not needed atm)
3.
6.
All the others points I find useful as well, but not that needed at the moment.

As my wife is bugging me on a special one: Photos are very high on the priority of my wife.