Hi all, first post
Using v. 1.2.1 both on openwrt and a stand alone debian 9 system, and have a collection of mp4 files that I'd like to sort by Track number. I set force_sort_criteria=+upnp:originalTrackNumber in the config file, and all sorts of various dlna clients still didn't sort it correctly (roku, vlc, bubble on andriod, windows media player etc...)
I opened the files in both mp3tag and tagscan to make sure they were correctly tagged with the Track numbers, and even tried reentering the track numbers in both of those programs but the clients were still not sorting correctly.
So then I "manually" opened the files.db database using DB browser for SQLite, http://sqlitebrowser.org/. Lo and Behold, in the Track column the values for all the files were "null". So I manually added track numbers to each of the files, saved the database, and... it worked. All dlna clients correctly sorted the files according to the Track numbers. Needless to say this method of manually changing the database file does not scale well for big collections or day-to-day use.
My conclusion is that minidlna/readymedia is not actually adding the Track data to the files.db database upon scanning. I looked a little in the source code at scanner.c but I'm not a coder. Can someone double check the code and make sure minidlna's actually adding the Track number to the database. I'd be VERY willing to try a patch out to see if it works.
Thanks :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all, first post
Using v. 1.2.1 both on openwrt and a stand alone debian 9 system, and have a collection of mp4 files that I'd like to sort by Track number. I set force_sort_criteria=+upnp:originalTrackNumber in the config file, and all sorts of various dlna clients still didn't sort it correctly (roku, vlc, bubble on andriod, windows media player etc...)
I opened the files in both mp3tag and tagscan to make sure they were correctly tagged with the Track numbers, and even tried reentering the track numbers in both of those programs but the clients were still not sorting correctly.
So then I "manually" opened the files.db database using DB browser for SQLite, http://sqlitebrowser.org/. Lo and Behold, in the Track column the values for all the files were "null". So I manually added track numbers to each of the files, saved the database, and... it worked. All dlna clients correctly sorted the files according to the Track numbers. Needless to say this method of manually changing the database file does not scale well for big collections or day-to-day use.
My conclusion is that minidlna/readymedia is not actually adding the Track data to the files.db database upon scanning. I looked a little in the source code at scanner.c but I'm not a coder. Can someone double check the code and make sure minidlna's actually adding the Track number to the database. I'd be VERY willing to try a patch out to see if it works.
Thanks :-)
See https://sourceforge.net/p/minidlna/bugs/320/#3be7