According to this Discogs page, the API used for querying the site in MP3 Diags stable up to 1.0.9 and MP3 Diags Unstable up to 1.1.08 will be turned off on January 15th. So I changed the code to use the new API. The unstable branch got the change in 1.1.09. Since it worked OK for me and I didn't receive any complaints from anybody else, I assumed it was OK and I backported the change to the stable branch, in version 1.0.10.
So anybody who wants to use the Discogs integration after January 15th 2012 should have one of these versions (or something newer, as I release them): 1.1.09 unstable or 1.0.10.
Saturday, December 31, 2011
Saturday, December 3, 2011
New Discogs API and various fixes in 1.1.09
The API that was used until now by MP3 Diags is supposed to be turned off, so I switched to the new one for the Unstable branch. This is just about how the program works internally; the user experience shouldn't change. Discogs queries for the Stable branch will probably stop working in the immediate future, at which point I'm going to backport the changes from the Unstable branch, if that seems to work fine. My tests went OK, but they weren't very comprehensive, so it would be a good idea for anyone who finds issues with querying Discogs in both branches to let me know about it.
Other changes:
Other changes:
- Copying song info from ID3V1 to ID3V2 no longer assumes Latin-1, but allows the user to specify a codepage
- I fixed a crash caused by ID3V2.4 tags with invalid flags
- A few other minor fixes
Saturday, September 10, 2011
Stable branch backports
When I said that the 1.0, stable branch was going to get only crash fixes, it didn't occur to me that the program might stop working even if it didn't change. Well, along came Gnome 3.0 and a Discogs API change and now you can't easily close a window with the mouse and you no longer can query Discogs.
These issues got fixed in the unstable branch. (Well, I guess "fixed" is a strong word, as I still don't like how the program looks on Gnome 3, but at least I can use the mouse to navigate.) The fixes have been backported to 1.0.09, so with this change it is now possible again to query Discogs in the stable branch.
These issues got fixed in the unstable branch. (Well, I guess "fixed" is a strong word, as I still don't like how the program looks on Gnome 3, but at least I can use the mouse to navigate.) The fixes have been backported to 1.0.09, so with this change it is now possible again to query Discogs in the stable branch.
Sunday, August 28, 2011
Discogs fixes
Getting album info from Discogs stopped working some time in the past few weeks, because Discogs changed their API. MP3 Diags 1.1.08 addresses this issue by making its own changes to match Discogs. I will quite likely backport this change to the 1.0, stable branch as well. There will be yet another, more radical change later this year.
There are 2 rather minor bug fixes as well:
Another change concerns the close buttons for dialogs under Gnome 3. Now most of the dialogs have close buttons. I might go back on this, as it seems that there should be no close buttons in Gnome 3, but I'd have to revisit all dialogs, to make sure they can be closed with the mouse.
There are 2 rather minor bug fixes as well:
- When using Discogs, track numbers for multi-volume albums are now (arguably) correct
- Shell integration on Linux now accepts file and folder names containing spaces
Another change concerns the close buttons for dialogs under Gnome 3. Now most of the dialogs have close buttons. I might go back on this, as it seems that there should be no close buttons in Gnome 3, but I'd have to revisit all dialogs, to make sure they can be closed with the mouse.
Sunday, July 31, 2011
Shell integration in Linux
I just published version 1.1.07 of MP3 Diags Unstable, which brings shell integration to Linux. Unlike Windows, getting this to work on Linux is trickier, because of the diversity of desktop environments and file browsers. So I'd be really surprised if this worked for everybody, but the situation can improve over time.
The program finally gets a Close button on Gnome 3, which it didn't have thus far (at any rate, it does on my virtual installation, which uses fallback mode; I don't know if that matters). It also got minimize and maximize buttons in Gnome 2 and 3.
There are some changes which affect packaging - I renamed some files to reflect that they belong to the "unstable" branch, and I also restructured the .spec file, based on feedback that I received from an anonymous user a while ago. I didn't make everything lowercase, though, as that seemed too big of a change.
These changes are Linux-specific, so there's no reason to update if you use Windows.
At the time that I write this there are no binaries with the new version at openSUSE Build Service, whose build process seems down. I'll keep trying to get the binaries to build.
The program finally gets a Close button on Gnome 3, which it didn't have thus far (at any rate, it does on my virtual installation, which uses fallback mode; I don't know if that matters). It also got minimize and maximize buttons in Gnome 2 and 3.
There are some changes which affect packaging - I renamed some files to reflect that they belong to the "unstable" branch, and I also restructured the .spec file, based on feedback that I received from an anonymous user a while ago. I didn't make everything lowercase, though, as that seemed too big of a change.
These changes are Linux-specific, so there's no reason to update if you use Windows.
At the time that I write this there are no binaries with the new version at openSUSE Build Service, whose build process seems down. I'll keep trying to get the binaries to build.
Saturday, July 23, 2011
Explorer intergation and more
After a long while, MP3 Diags finally got some new features. They all revolve around using command-line arguments.
First, Michael Elsdörfer sent me some code that allowed song information to be displayed in the console, without entering the GUI mode. Then I added options to create new, GUI sessions based on parameters passed to the program. Then I used these to add the possibility to integrate MP3 Diags with the file browser (only Windows Explorer works currently, though), so now you can right-click on a folder and have it open in MP3 Diags.
These are in the unstable, 1.1 branch and are documented in the Shell integration and Advanced features pages. Download links are here. If you don't really need these features I'd suggest to continue using the stable, 1.0 branch. I'd also suggest to packagers to stick with 1.0 or at least wait for a while (or perhaps provide both - the way I package the program, the stable and unstable versions are considered unrelated applications, which can be installed in parallel without interacting). I intend to fix any bugs that are discovered in the unstable version in a timely manner, provided that I get enough information to proceed.
I haven't decided what to do next but implementing the shell integration on Linux would make sense. I could use some help in this area - links to some documentation or examples would be great, as currently I'm quite clueless about how to achieve this programmatically.
I don't know if anybody noticed but there was a 1.1.05.058 version, which didn't correctly detect if it could actually configure the explorer integration. If you downloaded it early, you should replace it with 1.1.06.059, which at least works OK for me (I said "early" because after some 10 hours I posted a fix, without changing the version number).
If you have any opinions about these features, it would be a good idea to post them to this forum page.
First, Michael Elsdörfer sent me some code that allowed song information to be displayed in the console, without entering the GUI mode. Then I added options to create new, GUI sessions based on parameters passed to the program. Then I used these to add the possibility to integrate MP3 Diags with the file browser (only Windows Explorer works currently, though), so now you can right-click on a folder and have it open in MP3 Diags.
These are in the unstable, 1.1 branch and are documented in the Shell integration and Advanced features pages. Download links are here. If you don't really need these features I'd suggest to continue using the stable, 1.0 branch. I'd also suggest to packagers to stick with 1.0 or at least wait for a while (or perhaps provide both - the way I package the program, the stable and unstable versions are considered unrelated applications, which can be installed in parallel without interacting). I intend to fix any bugs that are discovered in the unstable version in a timely manner, provided that I get enough information to proceed.
I haven't decided what to do next but implementing the shell integration on Linux would make sense. I could use some help in this area - links to some documentation or examples would be great, as currently I'm quite clueless about how to achieve this programmatically.
I don't know if anybody noticed but there was a 1.1.05.058 version, which didn't correctly detect if it could actually configure the explorer integration. If you downloaded it early, you should replace it with 1.1.06.059, which at least works OK for me (I said "early" because after some 10 hours I posted a fix, without changing the version number).
If you have any opinions about these features, it would be a good idea to post them to this forum page.
Tuesday, May 31, 2011
Version 1.1 finally got started
It took me a lot longer than what I would have liked, but I managed to start working on the next version. Branching the program needed quite a bit of work, as there were many changes in the tools that do the building and packaging. Well, here's how it's supposed to work:
The new, "development" branch is called "unstable" and it gets its own place at the SourceForge download page, which mirrors the directory structure of the "stable", 1.0 release. The files' names contain "unstable", though. Version names will be 1.1.01, 1.1.02, ... until a new stable release will be created (probably 1.2)
In Subversion this new development takes place in trunk, while there is a new "1.0" branch created for the stable release. (Even though it's technically incorrect from Subversion's point of view, I will call the "1.1.x" release the "unstable branch", to emphasize that most people should keep using 1.0, which is for now the main, stable release.)
There is a separate on-line help system for the unstable branch. For now it's just a copy of 1.0, but that will change.
The Linux and Windows unstable binaries that I provide at SourceForge and OBS can be installed alongside the "stable" ones. Getting this to work wasn't very easy, but it seemed important. The "stable" and "unstable" versions are not aware of one another and normally they should use different sessions (they can be made to share sessions, but this is best avoided - making a copy would be preferred). Notification for new versions being available is also separate for the stable and unstable branches.
In 1.1.01 there is nothing new over 1.0.08 from a functional point of view. The changes mainly deal with the idea that the program knows that it's "unstable". Well, for the Windows build I switched to the latest Qt/MinGW, and this might have some impact, although I didn't notice anything. (I also plan to look at Visual Studio Express to see if it can make the program smaller.)
So basically 1.1.01 is for those curious to see if there is any negative impact from these changes, in which case I hope I will get notified. (I also noticed that the Linux binaries don't work as well as they did in the past, but this is an issue for 1.0 as well as 1.1)
For the casual users, it's better to stick to 1.0 until a new stable version gets released or there seems to be some really important feature in 1.1. While 1.1.x releases will get tested, 1.0 was tested more thoroughly. Also, I won't try very hard to keep setting or data compatibility in the unstable release, but I don't expect this to be a big issue.
The new, "development" branch is called "unstable" and it gets its own place at the SourceForge download page, which mirrors the directory structure of the "stable", 1.0 release. The files' names contain "unstable", though. Version names will be 1.1.01, 1.1.02, ... until a new stable release will be created (probably 1.2)
In Subversion this new development takes place in trunk, while there is a new "1.0" branch created for the stable release. (Even though it's technically incorrect from Subversion's point of view, I will call the "1.1.x" release the "unstable branch", to emphasize that most people should keep using 1.0, which is for now the main, stable release.)
There is a separate on-line help system for the unstable branch. For now it's just a copy of 1.0, but that will change.
The Linux and Windows unstable binaries that I provide at SourceForge and OBS can be installed alongside the "stable" ones. Getting this to work wasn't very easy, but it seemed important. The "stable" and "unstable" versions are not aware of one another and normally they should use different sessions (they can be made to share sessions, but this is best avoided - making a copy would be preferred). Notification for new versions being available is also separate for the stable and unstable branches.
In 1.1.01 there is nothing new over 1.0.08 from a functional point of view. The changes mainly deal with the idea that the program knows that it's "unstable". Well, for the Windows build I switched to the latest Qt/MinGW, and this might have some impact, although I didn't notice anything. (I also plan to look at Visual Studio Express to see if it can make the program smaller.)
So basically 1.1.01 is for those curious to see if there is any negative impact from these changes, in which case I hope I will get notified. (I also noticed that the Linux binaries don't work as well as they did in the past, but this is an issue for 1.0 as well as 1.1)
For the casual users, it's better to stick to 1.0 until a new stable version gets released or there seems to be some really important feature in 1.1. While 1.1.x releases will get tested, 1.0 was tested more thoroughly. Also, I won't try very hard to keep setting or data compatibility in the unstable release, but I don't expect this to be a big issue.
MP3 Diags 1.0.08 available
Nothing very exiting for this release - its main purpose is to add a half-fix for a crash before splitting the code to start working on version 1.1. There were some crashes reported when trying to save changes, which didn't make much sense, but investigating them led me to discover a related bug that is fixed now (although the original bug probably remains unfixed). Well, even if the change just managed to make that bug invisible, it seems to have solved the problem for the user, so I guess it's better to publish the fix now rather than wait for a full understanding of what was going on.
If you didn't experience crashes at startup or when saving, there's no point in upgrading.
There are also some script changes, in the tools that prepare the packages, not in the program's code. These are also related to the 1.1 split. I hope I didn't break anything; at any rate, I tested them and they seemed OK.
If you didn't experience crashes at startup or when saving, there's no point in upgrading.
There are also some script changes, in the tools that prepare the packages, not in the program's code. These are also related to the 1.1 split. I hope I didn't break anything; at any rate, I tested them and they seemed OK.
Tuesday, January 11, 2011
Correction: no portable MP3 Diags
Upon closer inspection it turned out that the link at Softpedia pointed to my ZIP at SourceForge, which contains the EXE and some DLLs. So there's no portable version of MP3 Diags after all. OTOH perhaps it's a good idea to do it, but I don't have the time to look at this. Any volunteers?
Thursday, January 6, 2011
Portable version available
Saturday, January 1, 2011
FIxed crash in folder filter
There was a crash that could occur with some particular folder names when trying to use the folder filter. Mario Schwalbe figured out what was wrong and implemented a solution, which is included in version 1.0.07.052.
Now it's possible to build the project on Fedora 13 and 14, thanks to a change indicated by Edward Sheldrake two months ago in a forum post.
I'm not so sure about Fedora 12, though. For some reason the servers at openSUSE Build Service get stuck while trying to compile a file. So I changed the version that I was using at OBS to 13, which would cause those upgrading from my Fedora repository at OBS to have the files rescanned. I'm not sure about it, but I expect Fedora 12 to be unable to use the repository. If that's the case, the solution is to either build from sources (assuming it works) or use one of my precompiled binaries.
Due to some changes at my ISP, I'm unable to log on currently, so I moved the alternative download place to Dropbox. This is mainly of interest to packagers, as that's the only place that contains the source + documentation bundle.
Now it's possible to build the project on Fedora 13 and 14, thanks to a change indicated by Edward Sheldrake two months ago in a forum post.
I'm not so sure about Fedora 12, though. For some reason the servers at openSUSE Build Service get stuck while trying to compile a file. So I changed the version that I was using at OBS to 13, which would cause those upgrading from my Fedora repository at OBS to have the files rescanned. I'm not sure about it, but I expect Fedora 12 to be unable to use the repository. If that's the case, the solution is to either build from sources (assuming it works) or use one of my precompiled binaries.
Due to some changes at my ISP, I'm unable to log on currently, so I moved the alternative download place to Dropbox. This is mainly of interest to packagers, as that's the only place that contains the source + documentation bundle.
Subscribe to:
Posts (Atom)
