Hi,
I've been playing with mediatomb for a few days now on a Ubuntu Jaunty desktop and like what I see. However, judging by the svn log and lack of forum activity this project is worryingly dormant. I'm writing this in the hope that development will pick up again in the future.
Here are some specific issues I'm having that I'd love to be able to solve:
1/ Jpeg's aren't oriented correctly in my player (a PS3). One possibly fix for this would be to have mt read the exif orientation flag and rotate accordingly as a transcode operation. The problem is I have to hack at the mt core code to extract the tags I need.
2/ I'd like to be able to extract IPTC data from my images so that I could organize by tag. To do this, I'll again have to hack at the mt core
3/ mt fails to read the any of the tags in my large collection of WMA files (WMA!? I know… I know …). I tried rebuilding w/ ffmpeg, but that didn't help… I tried libextractor but as soon as I try to add a wma file mt would hang… Again, I can hack at the mt metadata handling routines to customize the wma handling…
Metadata support is the common theme here. The current metadata handling is a little rigid because it is hardcoded to specific tools (albeit with numerous #ifdefs and the optional availability of libextractor)
Here's my thought on improving metadata handling
1/ Current metadata handling becomes a fallback
2/ In the config xml, create a new import config block, say .
3/ in that block, a command like associates a mimetype with a C++ handler object that takes precedence over the fallback. The handlers can be objects that were compiled into the server or extensions (aka plugins) placed in a standard directory
4/ , associates a mimtype with a script that outputs xml/json containing the metadata taking precedence over the fallback. This won't be high performance but it will give users more power to workaround those difficult corner cases
5/ If metadata extraction fails using the handler/script, the handler script can signal that it is appropriate to use the fallback or skip the file entirely
I'd also like a blue pony.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-12-01
I've started playing with a basic implementation that uses (1), (2), (4) and (5). I'll submit a patch when I have it working.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd like to put a vote in for #1 and #2. #3 is not much use to me as I've no WMA files :-)
I'm not much good at coding but would like to help out if I can.
After trying most of the media servers available for linux, media tomb is by far the best. It would be a great shame to see the project fall by the wayside.
Cheers
Skip
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-12-02
"I'd like to put a vote in for #1 and #2. #3 is not much use to me as I've no WMA files :-)"
a good thing :) one day I'll go back and re-rip my CD collection…
Whether or not you find the examples I gave useful to you, I'm hoping the added flexibility will be useful to everyone. Not having to hack at the core and recompile the server for import tweaks lowers to bar of entry for everyone.
"I'm not much good at coding but would like to help out if I can. "
well when I get something ready I'll get you to test. what distro are you running? realistically, probably won't get this done for another week or so, but you never know…
"After trying most of the media servers available for linux, media tomb is by far the best. It would be a great shame to see the project fall by the wayside."
have you tried coherence? It seems to be a very flexible system. The only trouble is nobody has bothered to make a filesystem backend as usable as mediatomb's. For me, the potential big advantage of coherence is it is written and can be extended in python. I'm very comfortable with python, especially given its awesome library coverage.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-12-03
here's the first shot at a patch (with instructions):
The whole year I have been busy with my 33 year old car so coding activities stopped completely. Now that I finally (and almost) finished the restoration, we hope to get back to MediaTomb.
Right now our first priority is to fix bugs that were submitted during our absence, check what features that are present in SVN and are not yet in the release are actually finished, disable features that are not yet finished, and finally get a release out.
The next step would be to finish all stuff that is almost done, but not yet releasable, I know we started quite a few parallel construction sites in SVN.
After that - a look at possible improvements, patches, etc.
So that's the rough plan…
I did not look at the patch yet, just one hint: never use std:: stuff, you will have to stick to our (unfortunately undocumented) zmm middleware.
Thanks for showing interest in what we do, let's hope we can get the project back on track.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2009-12-03
>After that - a look at possible improvements, patches, etc.
>So that's the rough plan…
no pressure. the stuff I'm working on scratches my own itch. I'm happy to submit patches and if others find them useful then that's great.
>I did not look at the patch yet, just one hint: never use std:: stuff, you will
>have to stick to our (unfortunately undocumented) zmm middleware.
yeah, I noticed that std wasn't being used (to maximize compatibility with lightweight embedded systems?) so I used zmm, following the usage elsewhere in the codebase.
Now I assume if I were to start working on a plugin framework, the plugins can use whatever they want provided they derive from the base class correctly. Not as flexible as c++ std lib (or boost) but better than the c std lib :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I've been playing with mediatomb for a few days now on a Ubuntu Jaunty desktop and like what I see. However, judging by the svn log and lack of forum activity this project is worryingly dormant. I'm writing this in the hope that development will pick up again in the future.
Here are some specific issues I'm having that I'd love to be able to solve:
1/ Jpeg's aren't oriented correctly in my player (a PS3). One possibly fix for this would be to have mt read the exif orientation flag and rotate accordingly as a transcode operation. The problem is I have to hack at the mt core code to extract the tags I need.
2/ I'd like to be able to extract IPTC data from my images so that I could organize by tag. To do this, I'll again have to hack at the mt core
3/ mt fails to read the any of the tags in my large collection of WMA files (WMA!? I know… I know …). I tried rebuilding w/ ffmpeg, but that didn't help… I tried libextractor but as soon as I try to add a wma file mt would hang… Again, I can hack at the mt metadata handling routines to customize the wma handling…
Metadata support is the common theme here. The current metadata handling is a little rigid because it is hardcoded to specific tools (albeit with numerous #ifdefs and the optional availability of libextractor)
Here's my thought on improving metadata handling
1/ Current metadata handling becomes a fallback
2/ In the config xml, create a new import config block, say .
3/ in that block, a command like associates a mimetype with a C++ handler object that takes precedence over the fallback. The handlers can be objects that were compiled into the server or extensions (aka plugins) placed in a standard directory
4/ , associates a mimtype with a script that outputs xml/json containing the metadata taking precedence over the fallback. This won't be high performance but it will give users more power to workaround those difficult corner cases
5/ If metadata extraction fails using the handler/script, the handler script can signal that it is appropriate to use the fallback or skip the file entirely
I'd also like a blue pony.
I've started playing with a basic implementation that uses (1), (2), (4) and (5). I'll submit a patch when I have it working.
Hi,
I'd like to put a vote in for #1 and #2. #3 is not much use to me as I've no WMA files :-)
I'm not much good at coding but would like to help out if I can.
After trying most of the media servers available for linux, media tomb is by far the best. It would be a great shame to see the project fall by the wayside.
Cheers
Skip
"I'd like to put a vote in for #1 and #2. #3 is not much use to me as I've no WMA files :-)"
a good thing :) one day I'll go back and re-rip my CD collection…
Whether or not you find the examples I gave useful to you, I'm hoping the added flexibility will be useful to everyone. Not having to hack at the core and recompile the server for import tweaks lowers to bar of entry for everyone.
"I'm not much good at coding but would like to help out if I can. "
well when I get something ready I'll get you to test. what distro are you running? realistically, probably won't get this done for another week or so, but you never know…
"After trying most of the media servers available for linux, media tomb is by far the best. It would be a great shame to see the project fall by the wayside."
have you tried coherence? It seems to be a very flexible system. The only trouble is nobody has bothered to make a filesystem backend as usable as mediatomb's. For me, the potential big advantage of coherence is it is written and can be extended in python. I'm very comfortable with python, especially given its awesome library coverage.
here's the first shot at a patch (with instructions):
https://sourceforge.net/tracker/?func=detail&aid=2907919&group_id=129766&atid=715782
The whole year I have been busy with my 33 year old car so coding activities stopped completely. Now that I finally (and almost) finished the restoration, we hope to get back to MediaTomb.
Right now our first priority is to fix bugs that were submitted during our absence, check what features that are present in SVN and are not yet in the release are actually finished, disable features that are not yet finished, and finally get a release out.
The next step would be to finish all stuff that is almost done, but not yet releasable, I know we started quite a few parallel construction sites in SVN.
After that - a look at possible improvements, patches, etc.
So that's the rough plan…
I did not look at the patch yet, just one hint: never use std:: stuff, you will have to stick to our (unfortunately undocumented) zmm middleware.
Thanks for showing interest in what we do, let's hope we can get the project back on track.
>After that - a look at possible improvements, patches, etc.
>So that's the rough plan…
no pressure. the stuff I'm working on scratches my own itch. I'm happy to submit patches and if others find them useful then that's great.
>I did not look at the patch yet, just one hint: never use std:: stuff, you will
>have to stick to our (unfortunately undocumented) zmm middleware.
yeah, I noticed that std wasn't being used (to maximize compatibility with lightweight embedded systems?) so I used zmm, following the usage elsewhere in the codebase.
Now I assume if I were to start working on a plugin framework, the plugins can use whatever they want provided they derive from the base class correctly. Not as flexible as c++ std lib (or boost) but better than the c std lib :)