Only noise with PyTone 2.3.1
Hello everybody PyTone 2.3.1 just plays noise (schschscshscsh....) on my ubuntu system. No problems with PyTone 2.3.0 as well PyTone 2.4.4. I do the same with every release: 1. python setup.py build_ext -i 2. cp conf/pytonerc pytonerc 3. setting musicbasedir in pytonerc 4. ./pytone -c pytonerc Any hints? Thank you in advance. Regards, René
On Mon, 4 Sep 2006, Rene Maurer wrote:
PyTone 2.3.1 just plays noise (schschscshscsh....) on my ubuntu system. No problems with PyTone 2.3.0 as well PyTone 2.4.4.
I do the same with every release:
1. python setup.py build_ext -i 2. cp conf/pytonerc pytonerc 3. setting musicbasedir in pytonerc 4. ./pytone -c pytonerc
Any hints?
Hmm, this is the second report. I now remember when I updated to the subversion version to test ReplayGain support I also had a case of noise when playing. I don't know whether the database rebuild or just a subsequent set of restarts fixed it. In fact I thought it was related to my soundcard or the kernel since it eventually worked without modifying Python code. Maybe someone having the problem can try to restart or rebuild the database and see if any of that makes a difference ? PS I also believed it may have been caused by my config-file being overwritten after doing the install, which is still a major issue for me as it bites me every new release I tried. I now hardlink the configfile :) Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Dag Wieers schrieb am Montag, den 04. September 2006:
On Mon, 4 Sep 2006, Rene Maurer wrote:
PyTone 2.3.1 just plays noise (schschscshscsh....) on my ubuntu system. No problems with PyTone 2.3.0 as well PyTone 2.4.4.
I do the same with every release:
1. python setup.py build_ext -i 2. cp conf/pytonerc pytonerc 3. setting musicbasedir in pytonerc 4. ./pytone -c pytonerc While upgrading the debian packages yesterday I had the same problem yesterday, but after fiddling a little bit with the config and deleting the database it worked....
Alex
Hi all, On 04.09.06, Dag Wieers wrote:
On Mon, 4 Sep 2006, Rene Maurer wrote:
PyTone 2.3.1 just plays noise (schschscshscsh....) on my ubuntu system. No problems with PyTone 2.3.0 as well PyTone 2.4.4.
I do the same with every release:
1. python setup.py build_ext -i 2. cp conf/pytonerc pytonerc 3. setting musicbasedir in pytonerc 4. ./pytone -c pytonerc
Any hints?
Hmm, this is the second report. I now remember when I updated to the subversion version to test ReplayGain support I also had a case of noise when playing. I don't know whether the database rebuild or just a subsequent set of restarts fixed it.
This is a byte-ordering problem. Somehow it doesn't appear with all configurations, that's why I didn't notice it in the first place. Anyway, the attached patch should fix this. It will be included in the next version, but you can easily include it in your packages.
In fact I thought it was related to my soundcard or the kernel since it eventually worked without modifying Python code. Maybe someone having the problem can try to restart or rebuild the database and see if any of that makes a difference ?
I doubt that rebuilding the database makes a difference (although Alex reported so).
PS I also believed it may have been caused by my config-file being overwritten after doing the install, which is still a major issue for me as it bites me every new release I tried. I now hardlink the configfile :)
I still don't fully understand the problem. Why do you change the global config file (in /etc) at all, except for distribution purposes? And in the latter case, there should be no problem anyway. The right place to configure PyTone is in ~/.pytone/pytonerc which will never be overwritten. Jörg
Joerg Lehmann wrote:
This is a byte-ordering problem. Somehow it doesn't appear with all configurations, that's why I didn't notice it in the first place.
Anyway, the attached patch should fix this. It will be included in the next version, but you can easily include it in your packages.
Joerg, Thank you very much for the patch. I am at work now, but I will try it out this evening... Kind regards, René
Rene Maurer wrote:
Joerg Lehmann wrote:
This is a byte-ordering problem. Somehow it doesn't appear with all configurations, that's why I didn't notice it in the first place.
Anyway, the attached patch should fix this. It will be included in the next version, but you can easily include it in your packages.
Joerg,
Thank you very much for the patch. I am at work now, but I will try it out this evening...
The patch works 'out of the box'. Rebuilding the database was not necessary. Thank you again René
On Mon, 4 Sep 2006, Joerg Lehmann wrote:
Hi all,
On 04.09.06, Dag Wieers wrote:
On Mon, 4 Sep 2006, Rene Maurer wrote:
PyTone 2.3.1 just plays noise (schschscshscsh....) on my ubuntu system. No problems with PyTone 2.3.0 as well PyTone 2.4.4.
I do the same with every release:
1. python setup.py build_ext -i 2. cp conf/pytonerc pytonerc 3. setting musicbasedir in pytonerc 4. ./pytone -c pytonerc
Any hints?
Hmm, this is the second report. I now remember when I updated to the subversion version to test ReplayGain support I also had a case of noise when playing. I don't know whether the database rebuild or just a subsequent set of restarts fixed it.
This is a byte-ordering problem. Somehow it doesn't appear with all configurations, that's why I didn't notice it in the first place.
Anyway, the attached patch should fix this. It will be included in the next version, but you can easily include it in your packages.
That was quick :)
PS I also believed it may have been caused by my config-file being overwritten after doing the install, which is still a major issue for me as it bites me every new release I tried. I now hardlink the configfile :)
I still don't fully understand the problem. Why do you change the global config file (in /etc) at all, except for distribution purposes? And in the latter case, there should be no problem anyway. The right place to configure PyTone is in ~/.pytone/pytonerc which will never be overwritten.
Well, the global config-file contains the configuration of the sound output and some other configuration options I consider 'global' (specific to the system). Kind regards, -- 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, hi Alex, On 04.09.06, Dag Wieers wrote:
Anyway, the attached patch should fix this. It will be included in the next version, but you can easily include it in your packages.
That was quick :)
I already had it in Subversion as it did bite me as well on an Intel machine. Strangely enough the unfixed version worked with an emu10k1 card on another little-endian machine. Anyway, it would be good if you could include this patch in your packages as it could be a bit of a show-stopper for many people.
PS I also believed it may have been caused by my config-file being overwritten after doing the install, which is still a major issue for me as it bites me every new release I tried. I now hardlink the configfile :)
I still don't fully understand the problem. Why do you change the global config file (in /etc) at all, except for distribution purposes? And in the latter case, there should be no problem anyway. The right place to configure PyTone is in ~/.pytone/pytonerc which will never be overwritten.
Well, the global config-file contains the configuration of the sound output and some other configuration options I consider 'global' (specific to the system).
I would have no problem removing the file from the setup.py file. Probably for you packagers this doesn't make a difference, anyway. Jörg
On Tue, 5 Sep 2006, Joerg Lehmann wrote:
On 04.09.06, Dag Wieers wrote:
Anyway, the attached patch should fix this. It will be included in the next version, but you can easily include it in your packages.
That was quick :)
I already had it in Subversion as it did bite me as well on an Intel machine. Strangely enough the unfixed version worked with an emu10k1 card on another little-endian machine.
Anyway, it would be good if you could include this patch in your packages as it could be a bit of a show-stopper for many people.
Ok, can you say what revisions we need ? diff -r oldrev:newrev http://path-to-svn/ subversion is great for pointing people to patches without having to produce them ;-)
PS I also believed it may have been caused by my config-file being overwritten after doing the install, which is still a major issue for me as it bites me every new release I tried. I now hardlink the configfile :)
I still don't fully understand the problem. Why do you change the global config file (in /etc) at all, except for distribution purposes? And in the latter case, there should be no problem anyway. The right place to configure PyTone is in ~/.pytone/pytonerc which will never be overwritten.
Well, the global config-file contains the configuration of the sound output and some other configuration options I consider 'global' (specific to the system).
I would have no problem removing the file from the setup.py file. Probably for you packagers this doesn't make a difference, anyway.
For me that is an improvement. Of course packagers then need to put it in place themselves. But every existing package definition will complain as it does not find the expected file. So it does not need direct communication. Packagers will understand what they need to do :) Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On 05.09.06, Dag Wieers wrote:
Ok, can you say what revisions we need ?
diff -r oldrev:newrev http://path-to-svn/
svn diff -r 110:137 https://www.luga.de/svn/PyTone/trunk essentially yields the patch I sent to you.
subversion is great for pointing people to patches without having to produce them ;-)
Indeed.
PS I also believed it may have been caused by my config-file being overwritten after doing the install, which is still a major issue for me as it bites me every new release I tried. I now hardlink the configfile :)
I still don't fully understand the problem. Why do you change the global config file (in /etc) at all, except for distribution purposes? And in the latter case, there should be no problem anyway. The right place to configure PyTone is in ~/.pytone/pytonerc which will never be overwritten.
Well, the global config-file contains the configuration of the sound output and some other configuration options I consider 'global' (specific to the system).
I would have no problem removing the file from the setup.py file. Probably for you packagers this doesn't make a difference, anyway.
For me that is an improvement. Of course packagers then need to put it in place themselves. But every existing package definition will complain as it does not find the expected file. So it does not need direct communication. Packagers will understand what they need to do :)
Ok, so I'll remove this file in the future. Jörg
* Joerg Lehmann <joerg@luga.de> [2006-09-05 13:00]:
I still don't fully understand the problem. Why do you change the global config file (in /etc) at all, except for distribution purposes? And in the latter case, there should be no problem anyway. The right place to configure PyTone is in ~/.pytone/pytonerc which will never be overwritten.
Well, the global config-file contains the configuration of the sound output and some other configuration options I consider 'global' (specific to the system).
I would have no problem removing the file from the setup.py file. Probably for you packagers this doesn't make a difference, anyway.
For me that is an improvement. Of course packagers then need to put it in place themselves. But every existing package definition will complain as it does not find the expected file. So it does not need direct communication. Packagers will understand what they need to do :)
Ok, so I'll remove this file in the future.
Jörg
And what about new config-options? How are they communicated then? With 2.3.1 there came new keys for rating for example ... I always used the diff from the new pytonerc to look if there is something new I should know about ;-) @Dag: I have for every version of pytone a pytonerc in /etc and a link to the currently used. Before every update I remove the link ... simple as that ;-) Luckily the whole problem does not exist in Gentoo since the files in /etc are protected and run through a diff-proces anyway. Just my thoughts Stefan ========================================================= My very personal wishlist for Pytone - just ignore it ;-) ========================================================= * BPS recognition Show the bits per seconds from a song in the MP3 info window * Pause between tracks * Some sort of replaygain * Extended search function -- Stefan Wimmer <swimmer@xs4all.nl>
On Tue, 5 Sep 2006, Stefan Wimmer wrote:
* Joerg Lehmann <joerg@luga.de> [2006-09-05 13:00]:
I still don't fully understand the problem. Why do you change the global config file (in /etc) at all, except for distribution purposes? And in the latter case, there should be no problem anyway. The right place to configure PyTone is in ~/.pytone/pytonerc which will never be overwritten.
Well, the global config-file contains the configuration of the sound output and some other configuration options I consider 'global' (specific to the system).
I would have no problem removing the file from the setup.py file. Probably for you packagers this doesn't make a difference, anyway.
For me that is an improvement. Of course packagers then need to put it in place themselves. But every existing package definition will complain as it does not find the expected file. So it does not need direct communication. Packagers will understand what they need to do :)
Ok, so I'll remove this file in the future.
And what about new config-options? How are they communicated then? With 2.3.1 there came new keys for rating for example ...
I always used the diff from the new pytonerc to look if there is something new I should know about ;-)
As a default, the setup.py could install it at /etc/pytonerc.default.
@Dag: I have for every version of pytone a pytonerc in /etc and a link to the currently used. Before every update I remove the link ... simple as that ;-)
I do that now as well on all my systems, after having had the problems. But it requires an action from the user before doing an upgrade or you may loose your old working configuration. That's an unacceptable situation imo. There is no warning, no user-interaction, nothing. It just overwrites the file...
Luckily the whole problem does not exist in Gentoo since the files in /etc are protected and run through a diff-proces anyway.
Also if you install from subversion ? Because I don't mind, RPM packages will not replace files in /etc either (unless you tell them to) but the problem always happens to me from subversion. Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
* Dag Wieers <dag@wieers.com> [2006-09-05 15:35]:
As a default, the setup.py could install it at /etc/pytonerc.default.
... Excellent idea!
@Dag: I have for every version of pytone a pytonerc in /etc and a link to the currently used. Before every update I remove the link ... simple as that ;-)
I do that now as well on all my systems, after having had the problems. But it requires an action from the user before doing an upgrade or you may loose your old working configuration. That's an unacceptable situation imo.
There is no warning, no user-interaction, nothing. It just overwrites the file...
... Point taken - I agree with you ... I just wanted to notice that I'd still like to know if something changes in the config ;-)
Luckily the whole problem does not exist in Gentoo since the files in /etc are protected and run through a diff-proces anyway.
Also if you install from subversion ? Because I don't mind, RPM packages will not replace files in /etc either (unless you tell them to) but the problem always happens to me from subversion.
... Until now I only use ebuilds and not subversion. As above said it's about the changes I want to know ...
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ --
Greetz Stefan -- Stefan Wimmer <swimmer@xs4all.nl>
Joerg Lehmann schrieb am Dienstag, den 05. September 2006:
Hi Dag, hi Alex,
On 04.09.06, Dag Wieers wrote:
Anyway, the attached patch should fix this. It will be included in the next version, but you can easily include it in your packages. Got it from cvs and uploaded to debian, fixed package should be available tomorrow.
PS I also believed it may have been caused by my config-file being overwritten after doing the install, which is still a major issue for me as it bites me every new release I tried. I now hardlink the configfile :)
I still don't fully understand the problem. Why do you change the global config file (in /etc) at all, except for distribution purposes? And in the latter case, there should be no problem anyway. The right place to configure PyTone is in ~/.pytone/pytonerc which will never be overwritten.
Well, the global config-file contains the configuration of the sound output and some other configuration options I consider 'global' (specific to the system). I would have no problem removing the file from the setup.py file. Probably for you packagers this doesn't make a difference, anyway. Maybe it would be good to allow a include, like /etc/pytone/pytonerc and /etc/pytone/pytonerc.local, so that users can add their changes to the local file and distributions can just overwrite the global config. This works good for packages like bind in Debian.
Just my 2 cents Alex
On Wed, 6 Sep 2006, Alexander Wirt wrote:
Joerg Lehmann schrieb am Dienstag, den 05. September 2006:
Hi Dag, hi Alex,
On 04.09.06, Dag Wieers wrote:
PS I also believed it may have been caused by my config-file being overwritten after doing the install, which is still a major issue for me as it bites me every new release I tried. I now hardlink the configfile :)
I still don't fully understand the problem. Why do you change the global config file (in /etc) at all, except for distribution purposes? And in the latter case, there should be no problem anyway. The right place to configure PyTone is in ~/.pytone/pytonerc which will never be overwritten.
Well, the global config-file contains the configuration of the sound output and some other configuration options I consider 'global' (specific to the system). I would have no problem removing the file from the setup.py file. Probably for you packagers this doesn't make a difference, anyway.
Maybe it would be good to allow a include, like /etc/pytone/pytonerc and /etc/pytone/pytonerc.local, so that users can add their changes to the local file and distributions can just overwrite the global config. This works good for packages like bind in Debian.
But, what would go into the default /etc/pytone/pytonerc that no-one should really need to change ? The current one is not sufficient because what I need to change on a global scale is the audio device configuration and the look and feel. Personally, what I do is put the default configuration file as part of the documentation as a reference. And this file is always overwritten upon installation of the package, not the real configuration file. Includes won't fix the problem we currently have with overwriting configuration files. Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Dag Wieers schrieb am Mittwoch, den 06. September 2006: *snip*
Maybe it would be good to allow a include, like /etc/pytone/pytonerc and /etc/pytone/pytonerc.local, so that users can add their changes to the local file and distributions can just overwrite the global config. This works good for packages like bind in Debian.
But, what would go into the default /etc/pytone/pytonerc that no-one should really need to change ? The current one is not sufficient because what I need to change on a global scale is the audio device configuration and the look and feel. Ah no, thats not directly what I meaned, that file should be empty by default and should be processed after the normal config, but before the user config. If a user wants to change something global he would enter only the changed variable into the .local file. Not more, so the global wouldn't get changed anymore.
Personally, what I do is put the default configuration file as part of the documentation as a reference. And this file is always overwritten upon installation of the package, not the real configuration file.
Includes won't fix the problem we currently have with overwriting configuration files. This won't happen on debian, if you changed the global config, the user will be asked if he wants to overwrite his config.
Alex
Hi Alex, On 06.09.06, Alexander Wirt wrote:
Anyway, the attached patch should fix this. It will be included in the next version, but you can easily include it in your packages. Got it from cvs and uploaded to debian, fixed package should be available tomorrow.
Fine. Thanks.
PS I also believed it may have been caused by my config-file being overwritten after doing the install, which is still a major issue for me as it bites me every new release I tried. I now hardlink the configfile :)
I still don't fully understand the problem. Why do you change the global config file (in /etc) at all, except for distribution purposes? And in the latter case, there should be no problem anyway. The right place to configure PyTone is in ~/.pytone/pytonerc which will never be overwritten.
Well, the global config-file contains the configuration of the sound output and some other configuration options I consider 'global' (specific to the system). I would have no problem removing the file from the setup.py file. Probably for you packagers this doesn't make a difference, anyway.
Maybe it would be good to allow a include, like /etc/pytone/pytonerc and /etc/pytone/pytonerc.local, so that users can add their changes to the local file and distributions can just overwrite the global config. This works good for packages like bind in Debian.
This is the obvious thing to do, but the problem is that the Python ConfigParser module upon which the whole PyTone config code is based doesn't allow you to do that. So PyTone would need to provide its own parser. Jörg
Teilnehmer (6)
-
Alexander Wirt -
Alexander Wirt -
Dag Wieers -
Joerg Lehmann -
Rene Maurer -
Stefan Wimmer