Hi! I just tried the audioscrobbler plugin for the first time. It works perfectly with MP3 files encoded with various rippers/encoders. With OGG files (created with jack) the audioscrobbler website tells me: 8<----------------------------------------------------- We detected a problem with a recent plugin submission: Incorrect length 8<----------------------------------------------------- I can't find any additional information about this problem, any ideas? Thank you! -- Andi
Hi Andreas, On 07.07.05, Andreas Poisel wrote:
I just tried the audioscrobbler plugin for the first time. It works perfectly with MP3 files encoded with various rippers/encoders.
With OGG files (created with jack) the audioscrobbler website tells me:
8<-----------------------------------------------------
We detected a problem with a recent plugin submission: Incorrect length
8<-----------------------------------------------------
I can't find any additional information about this problem, any ideas?
Actually, I have to admit that I do not know much about the AudioScrobller service. Maybe there is some expert on the list who can offer some help - and maybe even someone who wants to take over maintanership of the AudioScrobbler plugin. That's what the whole idea of the plugin system is after all, to take some load of me :-) Jörg
On Thu, 7 Jul 2005, Joerg Lehmann wrote:
On 07.07.05, Andreas Poisel wrote:
I just tried the audioscrobbler plugin for the first time. It works perfectly with MP3 files encoded with various rippers/encoders.
With OGG files (created with jack) the audioscrobbler website tells me:
8<-----------------------------------------------------
We detected a problem with a recent plugin submission: Incorrect length
8<-----------------------------------------------------
I can't find any additional information about this problem, any ideas?
Actually, I have to admit that I do not know much about the AudioScrobller service. Maybe there is some expert on the list who can offer some help - and maybe even someone who wants to take over maintanership of the AudioScrobbler plugin. That's what the whole idea of the plugin system is after all, to take some load of me :-)
Well, subversion access would be nice too. Not necessarily write access though, but at least to keep in sync with your latest developments. (subversion + commit mailinglist) I'd probably always use the latest snapshot myself and track changes. -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Hi Dag, On 08.07.05, Dag Wieers wrote:
On Thu, 7 Jul 2005, Joerg Lehmann wrote:
On 07.07.05, Andreas Poisel wrote:
I just tried the audioscrobbler plugin for the first time. It works perfectly with MP3 files encoded with various rippers/encoders.
With OGG files (created with jack) the audioscrobbler website tells me:
8<-----------------------------------------------------
We detected a problem with a recent plugin submission: Incorrect length
8<-----------------------------------------------------
I can't find any additional information about this problem, any ideas?
Actually, I have to admit that I do not know much about the AudioScrobller service. Maybe there is some expert on the list who can offer some help - and maybe even someone who wants to take over maintanership of the AudioScrobbler plugin. That's what the whole idea of the plugin system is after all, to take some load of me :-)
Well, subversion access would be nice too. Not necessarily write access though, but at least to keep in sync with your latest developments. (subversion + commit mailinglist)
I know this is a bit embarassing but I have to admit that up to now PyTone has been developped without using any version control system... From time to time, I thought about starting a repository but the only option for doing so was to move the project to SourceForge. I never actually did this, mainly because of SF's file release system, which is really a PITA. Note also, that SF still does not support subversion, so you're left with CVS (which would be ok for me, since I'm used to it). Anyway, I'm not against opening the development process of PyTone. So if there is really interest in CVS/Subversion access, I'd reconsider moving the project to SF. Jörg
Joerg Lehmann schrieb am Freitag, den 08. Juli 2005: *snip*
system... From time to time, I thought about starting a repository but the only option for doing so was to move the project to SourceForge. I never actually did this, mainly because of SF's file release system, which is really a PITA. Note also, that SF still does not support subversion, so you're left with CVS (which would be ok for me, since I'm used to it). I'm able to provide webspace and also subversion via webdav for pytone. Thats much more reliable than sourceforge ;).
Best wishes Alex
system... From time to time, I thought about starting a repository but the only option for doing so was to move the project to SourceForge. I never actually did this, mainly because of SF's file release system, which is really a PITA. Note also, that SF still does not support subversion, so you're left with CVS (which would be ok for me, since I'm used to it).
I'm able to provide webspace and also subversion via webdav for pytone. Thats much more reliable than sourceforge ;).
Allow me to suggest that you use darcs. (http://darcs.net) I've used CVS, subversion, and arch and just reciently started using darcs for my dancebox project and playing with it in tandem for a few CVS projects. Its braindead easy to set up and the distributed nature of it is _really_ nice. SF dosen't support darcs directly but you can put the repository up in the webspace (its just a directory) and people can pull from there. Its intuitive and just seems to work. The only drawback I've found so far is that it can be a little slow at times and on windows there are a few quirks. The new developement branch is said to have much improvment in these areas. A nifty side is that the new developement stuff will also work with kernel git trees. -- Richard A. Smith
Richard Smith schrieb am Freitag, den 08. Juli 2005:
system... From time to time, I thought about starting a repository but the only option for doing so was to move the project to SourceForge. I never actually did this, mainly because of SF's file release system, which is really a PITA. Note also, that SF still does not support subversion, so you're left with CVS (which would be ok for me, since I'm used to it).
I'm able to provide webspace and also subversion via webdav for pytone. Thats much more reliable than sourceforge ;).
Allow me to suggest that you use darcs. (http://darcs.net) I've used CVS, subversion, and arch and just reciently started using darcs for my dancebox project and playing with it in tandem for a few CVS projects. Seconded, I love darcs and I still mangage several darcs repos on my server, so this is available too.
Best wishes Alex
Richard Smith schrieb am Freitag, den 08. Juli 2005:
Seconded, I love darcs and I still mangage several darcs repos on my server, so this is available too.
So you can set it up where we can push to the repo as well then? I'm willing to give ssh accounts on my box if there aren't too much people that needs access. Unfortunatly darcs isn't able to do webdav, that would be great...
Yours sincerly Alex
So you can set it up where we can push to the repo as well then? I'm willing to give ssh accounts on my box if there aren't too much people that needs access. Unfortunatly darcs isn't able to do webdav, that would be great...
Thinking about it there really isn't much traffic for pyTone so I bet that just using the darcs generated email patches would suffice. -- Richard A. Smith
Hi, On 08.07.05, Alexander Wirt wrote:
Richard Smith schrieb am Freitag, den 08. Juli 2005:
Seconded, I love darcs and I still mangage several darcs repos on my server, so this is available too.
So you can set it up where we can push to the repo as well then? I'm willing to give ssh accounts on my box if there aren't too much people that needs access.
Many thanks for your generous offer, Alex. Maybe I'll come back to it, it's certainly an alternative for SourceForge. I'll also consider setting up a subversion repository on the LUGA server. If this doesn't take too much effort to adminstrate, this would also be an option.
Unfortunatly darcs isn't able to do webdav, that would be great...
Concerning darcs, I just read the descriptive paragraph on its webpage. To quote: "Darcs is decentralized, based on a "theory of patches" with roots in quantum mechanics." Sorry, but I'd rather not use a system which describes it's working principle in such a way - I really don't know what quantum mechanics and version control systems should have in common. Jörg
"Darcs is decentralized, based on a "theory of patches" with roots in quantum mechanics."
Sorry, but I'd rather not use a system which describes it's working
The author is a physicist. He attacked the problem of revision control the same way he approached his research into quantum physics.
principle in such a way - I really don't know what quantum mechanics and version control systems should have in common.
Each patch is treated as a quantum unit in his system. A tree is comprised of a set of patches. Its very similar to the way that gnu-arch and git work. But don't let all that talk scare you. darcs is _very_ easy to work with. I find its easier than Subversion and _much_ easier than Arch. At least read this recommendation before you bail... http://lwn.net/Articles/109719/ -- Richard A. Smith
Hi, On 12.07.05, Richard Smith wrote:
"Darcs is decentralized, based on a "theory of patches" with roots in quantum mechanics."
Sorry, but I'd rather not use a system which describes it's working
The author is a physicist. He attacked the problem of revision control the same way he approached his research into quantum physics.
I have nothing against quantum physics, in fact that is what I'm doing in my "academic life". Being a physicists myself, I am, however, a bit sensible when people try to take concepts from modern physics and claim that they are relevant for a completely unrelated field. But that's my personal point of view, and I certainly do not want to say that darcs is a bad system just because of this kind of "advertisement".
principle in such a way - I really don't know what quantum mechanics and version control systems should have in common.
Each patch is treated as a quantum unit in his system. A tree is comprised of a set of patches. Its very similar to the way that gnu-arch and git work. But don't let all that talk scare you. darcs is _very_ easy to work with. I find its easier than Subversion and _much_ easier than Arch.
If I understood git correctly, it doesn't store any patches but always the full versions of the files and the state of the tree, identified by some hash. On the other hand, it seems like darcs really stores the patches themselves. I hope, it stores a copy of the last version, as well, otherwise I'd certainly not entrust my data to it.
At least read this recommendation before you bail...
Thanks for the link. Although I highly esteem the quality of LWN, I'm still not convinced. Actually the main reason for not switching to something like darcs, is that when it comes to version-control systems, I prefer to be pretty mainstream. The reason for this simple is that I want to have such a system being maintained even after a few years. Advanced features like the support for sophisticated branching and merging algorithms or methodologies are really secondary for me. That's why I always had in mind to use Subversion for a new project. And actually, I today found some time to read a little bit in the Subversion book (which actually is an excellent resource and another reason to choose this VCS). And, since I finally managed to upgrade the luga.de Apache server to Apache 2, it was really straightforward to setup a Subversion-DAV-Repository. And here it is: https://www.luga.de/svn/PyTone/ Read-only access is available to everybody, write access currently only to me. But if there should be some serious interest in getting write access, I'd happily provide that. Alex, thanks again for your offer to host the repository. I really was considering to accept it, but then the Subversion repository was so simple to setup... Jörg
that they are relevant for a completely unrelated field. But that's my personal point of view, and I certainly do not want to say that darcs is a bad system just because of this kind of "advertisement".
Well I _think_ its just set theory. But I'm stepping out of my area of expertise so I'll not try generalize further.
If I understood git correctly, it doesn't store any patches but always the full versions of the files and the state of the tree, identified by some hash. On the other hand, it seems like darcs really stores the patches themselves. I hope, it stores a copy of the last version, as well, otherwise I'd certainly not entrust my data to it.
Arg.. I seem to have jumbled up my statements. I was also trying to work in the concept of mutiple tree distributed stuff and peer related facilities of arch and git but I botched it. Sorry. Too much caffeine when I wrote that.
something like darcs, is that when it comes to version-control systems, I prefer to be pretty mainstream. The reason for this simple is that I want to have such a system being maintained even after a few years. Advanced features like the support for sophisticated branching and merging algorithms or methodologies are really secondary for me. That's why I always had in mind to use Subversion for a new project.
Can't argue with that. My biggest beef with svn is the way the repository is versioned. Its not suited well for mutiple unrelated projects. My eval of svn was centered around my professional work as an embedded developer and software manager. Where our CVS repo has dozens of different projects all in seperate modules. Now unless I totally missed something with svn if I wan't to maintain a seperate version number for each of those projects I have to have seperate repositorys. Setting up a repo requires admin access. So I have to either give admin access to my other developers or they have me do it when they want a new module. (Or I guess I could make some sort of automated web) . But its just a pain. Darcs has been allmost a drop in CVS replacement and overall really fits in with the way my developer team likes to work. In fact better than CVS did. No central repository is really nice. I'm sure svn will work great for pyTone though and I look forward to learning a bit more about its use "in the wild" -- Richard A. Smith
Hi Richard, On 16.07.05, Richard Smith wrote: [snip]
Can't argue with that. My biggest beef with svn is the way the repository is versioned. Its not suited well for mutiple unrelated projects. My eval of svn was centered around my professional work as an embedded developer and software manager. Where our CVS repo has dozens of different projects all in seperate modules.
Now unless I totally missed something with svn if I wan't to maintain a seperate version number for each of those projects I have to have seperate repositorys. Setting up a repo requires admin access. So I have to either give admin access to my other developers or they have me do it when they want a new module. (Or I guess I could make some sort of automated web) . But its just a pain.
You're right, it's really not nice if revision numbers are shared between different projects. And in addition, besides adding some administrative overhead when you always have to setup a new repository for every new project this iss also not optimal if you want to share things like hooks between different projects.
Darcs has been allmost a drop in CVS replacement and overall really fits in with the way my developer team likes to work. In fact better than CVS did. No central repository is really nice.
I agree that systems without central repository may have advantages in certain cases. One just has to look at the tremendously successful use of such a system in the case of the Linux kernel development.
I'm sure svn will work great for pyTone though and I look forward to learning a bit more about its use "in the wild"
Let's see how it works out - it's certainly better than having no version-control system at all ;-) Jörg
Ok... This is the last thing I'll say about this... Promise.
Thanks for the link. Although I highly esteem the quality of LWN, I'm still not convinced. Actually the main reason for not switching to
Here's a slightly stronger endorsement from a KDE developer after switching to svn... http://www.kdedevelopers.org/node/1028 -- Richard A. Smith
On 16.07.05, Richard Smith wrote:
Ok... This is the last thing I'll say about this... Promise.
Thanks for the link. Although I highly esteem the quality of LWN, I'm still not convinced. Actually the main reason for not switching to
Here's a slightly stronger endorsement from a KDE developer after switching to svn...
Thanks. This blog has more beef than the LWN article. Still, I think for the moment, a Subversion repository fits the needs of PyTone rather well. If later, one of the new kids on the block (darcs, monotone, git, etc.) turns out to provide some really useful functionality for us, we can still switch. And then we can almost certainly profit from one the advantages of using a mainstream system, namely that there are good chances that there is a migration path from svn to system XYZ - at least as far as the "impedance mismatch" between different systems allows this. Jörg
Teilnehmer (5)
-
Alexander Wirt -
Andreas Poisel -
Dag Wieers -
Joerg Lehmann -
Richard Smith