Project

General

Profile

Bug #570

The size of the playlist is strangely restricted

Added by Victor Dymov over 9 years ago. Updated over 9 years ago.

Status:
Rejected
Priority:
Minor
Assignee:
-
Category:
-
Target version:
-
Start date:
August 21, 2015
Due date:
% Done:

0%

Estimated time:
Affects version:

Description

As I can see Audacious keeps the playlist from start to start in the file ~/.config/audacious/playlists/%UID%.audpl
There is a little problem.
The potential size of the playlist during runtime is long enough, so i can't reach the max songs number.
But there are only 803 list items kept in the file mentioned above.
It's pretty inconvenient to make list about one thousand items which transfers to 803 items list after restart.

History

#1 Updated by Victor Dymov over 9 years ago

Correction: detailed investigation of current case shows there aren't restrictions on the size of the playlist. But the playlist becomes unsaveable if a song name contains character 0xFC
To be more exact Audacious does not save the part of the playlist after the character 0xFC

#2 Updated by John Lindgren over 9 years ago

  • Category deleted (libaudgui)

Thank you for the bug report. It is unfortunately missing a lot of necessary information. Please answer the following questions:

1. By "song name" do you mean the filename or the title from the ID3 tag?
2. By "the character 0xfc", do you mean the Unicode character ü, encoded in UTF-8 as 0xc3 0xb3, or do you mean a raw byte with value 0xfc?
3. By "does not save the playlist after the character 0xfc", do you mean that the file is literally truncated after that character, in the middle of the song name?
4. How does "the character 0xfc" appear in the resulting playlist? It ought to be encoded as %C3%BC.
5. How did you add the file to the playlist? Command-line? "Add Files" dialog? Drag and drop?
6. What is your system locale set to?
7. What are your character encoding settings in Audacious?
8. Is the character correctly displayed as ü while Audacious is running?
9. Does the problem still occur with Audacious 3.6.2?

#3 Updated by Victor Dymov over 9 years ago

John Lindgren wrote:

Thank you for the bug report. It is unfortunately missing a lot of necessary information. Please answer the following questions:

1. By "song name" do you mean the filename or the title from the ID3 tag?

Actually I mean a value of TITLE-field in a TRACK-section of a *.cue file

2. By "the character 0xfc", do you mean the Unicode character ü, encoded in UTF-8 as 0xc3 0xb3, or do you mean a raw byte with value 0xfc?

I mean a raw byte with value 0xfc

Yepppp... I have to say I'm an idiot. Problem is solved by "iconv -f cp1252 -t utf8 file.cue > file.utf8.cue".

3. By "does not save the playlist after the character 0xfc", do you mean that the file is literally truncated after that character, in the middle of the song name?

If the character is in the song name of FLAC, than yes, it's trunkated. But if that character is in *.cue file, than all of tracks from such *.cue file disappears.

4. How does "the character 0xfc" appear in the resulting playlist? It ought to be encoded as %C3%BC.

I can't say that I deeply understand where grabbers take value of TITLE-field in *.cue files but I often see value of TITLE-field with umlauts, not escaped by %%

5. How did you add the file to the playlist? Command-line? "Add Files" dialog? Drag and drop?

Drag'n'Drop or "Add Files" dialog

6. What is your system locale set to?

en_US.UTF-8

7. What are your character encoding settings in Audacious?

UTF-8

8. Is the character correctly displayed as ü while Audacious is running?

No, it isn't

9. Does the problem still occur with Audacious 3.6.2?

I don't know but I'll build 3.6.2 and try.

Excuse me for inconvenience. I had to check encoding of the *.cue-file before adding this issue. A thousand of apologies.

#4 Updated by John Lindgren over 9 years ago

Victor Dymov wrote:

7. What are your character encoding settings in Audacious?

UTF-8

Try adding CP1252 as a fallback character encoding in Audacious and see if that solves the problem.

#5 Updated by John Lindgren over 9 years ago

  • Status changed from New to Rejected

Also available in: Atom PDF