Do I understand correctly:
If I have x albums like "Études":
- An "É pocket" will be created (and x entries reserved for that).
- The album will be sorted in the "E pocket" regardless.
- The count for "E" albums is wrong (+x, because É is counted, too).
- That results in shifting the last x
FWIW: I wrote to the SQLite mailing list. And either I didn't describe
the problem well enough, or there's no clear opinion about whether this
is supposed to be working the way we expect it to work or not...
Hm... the conclusion basically is: localization is difficult. From the
SQLite
MrC wrote:
> Thanks for your time and perseverance, whatever the outcome.
+1
Its just an annoyance not a show stopper.
VB2.4[/B] STORAGE *QNAP TS419P (NFS)
[B]Living Room* - Joggler & SB3 -> Onkyo TS606 -> Celestion F20s
*Office* - Pi3+Sreen -> Sony TAFE320 -> Celestion F10s / Pi2+DAC &
Thanks for your time and perseverance, whatever the outcome.
MrC's Profile: http://forums.slimdevices.com/member.php?userid=468
View this thread: http://forums.slimdevices.com/showthread.php?t=110147
FWIW: I wrote to the SQLite mailing list. And either I didn't describe
the problem well enough, or there's no clear opinion about whether this
is supposed to be working the way we expect it to work or not...
Discussion is ongoing.
--
Michael
___
mherger wrote:
> > Database Version: DBD::SQLite 1.34_01 (sqlite 3.7.7.1)
> > Database Version: DBD::SQLite 1.58 (sqlite 3.22.0)
>
> I mentioned a few postings up that 7.9.1 was behaving differently. 7.9.1
>
> is using DBD::SQLite 1.34_01, like your "working" version. What I mean
> by this
Database Version: DBD::SQLite 1.34_01 (sqlite 3.7.7.1)
Database Version: DBD::SQLite 1.58 (sqlite 3.22.0)
I mentioned a few postings up that 7.9.1 was behaving differently. 7.9.1
is using DBD::SQLite 1.34_01, like your "working" version. What I mean
by this is that this version behaves
mherger wrote:
> > Not my area of skills at all ... but ... could LMS define its own
> > collation then, I assume, it would know what to expect when it comes
> > back from queries.
>
> We are using collations. Alas, they only seem to be used in the sorting
>
> order, but not the grouping. I'm
Not my area of skills at all ... but ... could LMS define its own
collation then, I assume, it would know what to expect when it comes
back from queries.
We are using collations. Alas, they only seem to be used in the sorting
order, but not the grouping. I'm trying to get an answer from
Not my area of skills at all ... but ... could LMS define its own
collation then, I assume, it would know what to expect when it comes
back from queries.
https://www.sqlite.org/c3ref/create_collation.html
Paul Webster
http://dabdig.blogspot.com
Author Radio France (FIP etc) plugin
Sting
Šuma Čovjek
Suzanne Vega
Heh... went back to 7.7 to see whether this was a regression. And in
this case Š comes _before S in the index bar... Not a regression then,
just f... up in a different way.
--
Michael
___
Squeezecenter mailing list
How does iPeng get it right?
That's a question pippin would have to answer. I wouldn't be surprised
if he did the grouping locally on device.
--
Michael
___
Squeezecenter mailing list
Squeezecenter@lists.slimdevices.com
Years ago I wrote a "scriptlet" (plug-in Perl module code called via a
higher-level driver program). Can this idea help for mappings?
We do this kind of transliteration for the search, but not the sorting.
But I'm not sure we want to use the transliterated character for the
grouping, as this
Maybe this helps in any way:
26704
The album "Eybler: Christmas Oratorio" is the last entry of "pocket E"
while "Eybler: Die vier letzten Dinge" is the first one in "pocket Ã".
The album "Ãcho" is found not in the "Ã" but in the "E pocket".
The "Ã pocket" does not contain any album
mherger wrote:
> Wow... now that I see this I wonder how this could possible have gone
> unseen... or how this changed recently...
>
> The problem is that while we do use a SQLite collation for the language
>
> specific sorting, extracting the first character does not apply the same
>
>
Years ago I wrote a "scriptlet" (plug-in Perl module code called via a
higher-level driver program). Can this idea help for mappings?
Code:
package Uni2Ascii;
# Transliterates Unicode input into its approximate ASCII equivalent in terms
of pronunciation.
#
Wow... now that I see this I wonder how this could possible have gone
unseen... or how this changed recently...
The problem is that while we do use a SQLite collation for the language
specific sorting, extracting the first character does not apply the same
logic. In my case I eg. have a sort
MrC wrote:
> Here's the issue in screenie form:
>
> 26697
Cant screen shot but its exactly the same in my Artist listing. The
first item in A (with character) - B is Azzido de Bass then an artist
called B
VB2.4[/B] STORAGE *QNAP TS419P (NFS)
[B]Living Room* - Joggler & SB3 -> Onkyo
Here's the issue in screenie form:
26697
+---+
|Filename: lettergroupings.png |
|Download: http://forums.slimdevices.com/attachment.php?attachmentid=26697|
I have a similar issue with Artists where I have extra A and extra O
type characters (cant type them on iOS easily). They appear in LMS
default skin and in Material where extra buckets get dressed but not in
ipeng where the listing is pure EN alphabetical. Clearly iPeng uses a
different method
I'm posting this issue as a new thread to avoid (further) hijacking the
Material Skin thread.
The basic issue is that I believe Albums are not getting placed
correctly into the Album letter groupings. It appears LMS is using the
Album's actual name to generate first character groupings, and yet
21 matches
Mail list logo
