|
|
Post by Eckless on May 25, 2018 15:54:45 GMT -5
Thank you for the update! I can report that with the fix you suggested about developer settings, Android Auto works fine. Regarding the "large libraries on Oreo" - I can say I have 11K tracks and GoneMAD doesn't have a problem at all. Thank you! Tiny bug #1 that I can live with: When looking at the tracks within an album in the Library view, sorting by "Track Num" doesn't take "Disc #" into account - it sorts as "track 1, disc 1", "track 1, disc 2", "track 2, disc 1", etc. It should sort "track 1, disc 1", "track 2, disc 1", etc. Tiny bug #2 that I can live with: When moving the (I think it's called the "scrubber"?) to quickly seek within a track on the "now playing" page, say you're at time A. You press time B. The music immediately goes to B, but the little dot on the scrubber goes A-B-A and then back to B. Again, completely minor. This doesn't happen every time - perhaps 1 out of 3.  |
|
|
|
Post by GoneMAD on May 25, 2018 17:18:33 GMT -5
Thank you for the update! I can report that with the fix you suggested about developer settings, Android Auto works fine. Regarding the "large libraries on Oreo" - I can say I have 11K tracks and GoneMAD doesn't have a problem at all. Thank you! Tiny bug #1 that I can live with: When looking at the tracks within an album in the Library view, sorting by "Track Num" doesn't take "Disc #" into account - it sorts as "track 1, disc 1", "track 1, disc 2", "track 2, disc 1", etc. It should sort "track 1, disc 1", "track 2, disc 1", etc. Tiny bug #2 that I can live with: When moving the (I think it's called the "scrubber"?) to quickly seek within a track on the "now playing" page, say you're at time A. You press time B. The music immediately goes to B, but the little dot on the scrubber goes A-B-A and then back to B. Again, completely minor. This doesn't happen every time - perhaps 1 out of 3. Great! I think the dupes on oreo only happen when the scanner gets restarted due to the 10 min limit. My xz2 compact has a 400gb sdcard filled with about 50k songs on it and it takes like 25 minutes to scan. My best guess is when android restarts the scan.. it actually makes 2 scans happen at the same time. Thats the only scenario i can think of that could cause dupes (plus i only see them after that initial 10 min period.. granted i wasnt looking very hard) bug #1: i'll mark that on trello bug #2: this actually happens sometimes on 2.x as well. Basically the UI refreshes and gets the current time before the audio engine has seeked to the new time yet. I'll probably have to put in some specific logic to have the seekbar not refresh for like a second or 2 after seeking |
|
|
|
Post by Eckless on May 25, 2018 21:09:01 GMT -5
Took GoneMAD to the gym to have some good solid time to play with it. Go into "Effects" and select the "Techno" setting on the equalizer. On the "Effects" page turn on the Virtualizer and set to 50%. Then go into the sandwich menu and go to "Now Playing" and hit play. Then if you go back to the Effects tab, two things: * It's still set to "Techno" and the numbers on the right side of the screen are correct, but the sliders are all in the wrong place. * The virtualizer will be set to 80%. (Also the Tempo will be set to 200%, etc.) (I'm guessing the settings are all fine internally, but the screens on the effects tabs aren't displaying appropriately) Thank you! |
|
|
|
Post by Eckless on May 26, 2018 8:58:34 GMT -5
There is a bug with the "next track" button on the now playing screen. In the middle of track "n" hit the "next track" button. Track "n+1" works as normal. But when track "n+2" starts, the "now playing" information is for track "n+2" but track "n+1" plays again. I think I explained that correctly. |
|
|
|
Post by DonTay89 on May 26, 2018 9:26:16 GMT -5
I'm on 3.0a1b and have four more things to report, but I'm not sure if the first three should fall under "bugs" or "old features you haven't implemented yet":
1. Long pressing the play/pause button doesn't have an effect. It should stop the track and reset the time back to 00:00.
2. If the last track in a queue is active, the R to L swipe/next track button doesn't do anything. It should trigger the "On queue completion" action, but I have to move the seekbar close to the end for the song to finish to trigger this.
3. On the now playing screen, swiping from the left edge would previously open the hamburger menu, but now it cause the song to change and I have to press the menu icon.
4. I've used the app probably no more than 2 hours total since it was first released. Yesterday, I was listening to an 44-minute album straight through and when track 6/13 started, it played the audio of track 3 with the metadata of track 6. I fixed it by going to the previous track and then reloading track 6 again. This happened again when playing a playlist created by the "on completion > shuffle" feature and I don't know how deep I was into the playlist, but it was probably 6-10 songs in and I probably skipped a few, too. I haven't tried to figure out how to reproduce this yet.
|
|
|
|
Post by GoneMAD on May 26, 2018 16:35:18 GMT -5
I'm on 3.0a1b and have four more things to report, but I'm not sure if the first three should fall under "bugs" or "old features you haven't implemented yet": 1. Long pressing the play/pause button doesn't have an effect. It should stop the track and reset the time back to 00:00. 2. If the last track in a queue is active, the R to L swipe/next track button doesn't do anything. It should trigger the "On queue completion" action, but I have to move the seekbar close to the end for the song to finish to trigger this. 3. On the now playing screen, swiping from the left edge would previously open the hamburger menu, but now it cause the song to change and I have to press the menu icon. 4. I've used the app probably no more than 2 hours total since it was first released. Yesterday, I was listening to an 44-minute album straight through and when track 6/13 started, it played the audio of track 3 with the metadata of track 6. I fixed it by going to the previous track and then reloading track 6 again. This happened again when playing a playlist created by the "on completion > shuffle" feature and I don't know how deep I was into the playlist, but it was probably 6-10 songs in and I probably skipped a few, too. I haven't tried to figure out how to reproduce this yet. 1) yea long press isnt coded yet 2) agreed 3) left edge swiping is intentionally disabled on now playing because it interferes with the gestures and the seekbar 4) is this 2 separate cases where you got the bug? 44 min album straight through (1 through 13) and then again with on completion shuffle? |
|
|
|
Post by DonTay89 on May 26, 2018 18:17:01 GMT -5
I'm on 3.0a1b and have four more things to report, but I'm not sure if the first three should fall under "bugs" or "old features you haven't implemented yet": 1. Long pressing the play/pause button doesn't have an effect. It should stop the track and reset the time back to 00:00. 2. If the last track in a queue is active, the R to L swipe/next track button doesn't do anything. It should trigger the "On queue completion" action, but I have to move the seekbar close to the end for the song to finish to trigger this. 3. On the now playing screen, swiping from the left edge would previously open the hamburger menu, but now it cause the song to change and I have to press the menu icon. 4. I've used the app probably no more than 2 hours total since it was first released. Yesterday, I was listening to an 44-minute album straight through and when track 6/13 started, it played the audio of track 3 with the metadata of track 6. I fixed it by going to the previous track and then reloading track 6 again. This happened again when playing a playlist created by the "on completion > shuffle" feature and I don't know how deep I was into the playlist, but it was probably 6-10 songs in and I probably skipped a few, too. I haven't tried to figure out how to reproduce this yet. 1) yea long press isnt coded yet 2) agreed 3) left edge swiping is intentionally disabled on now playing because it interferes with the gestures and the seekbar 4) is this 2 separate cases where you got the bug? 44 min album straight through (1 through 13) and then again with on completion shuffle? Good to know on #1-3. For #4, it was two separate cases. I just tried to reproduce by listening to a 15-track 17 minute album all the way through and then the 44-minute album, but had no luck. Then, I rearranged several of the upcoming tracks in the queue and played one to completion. It reproduced the bug(!), but I could only get it to happen about 2 out of 5 times. So it seems the bug is related to rearranging the queue and not the length or amount of tracks. Also while trying to reproduce #4, I found another new bug: 5. If I unplug my Nexus 6P while playing a song, the music pauses as if I disconnected a headset. Plugging it back in resumes the song. |
|
|
|
Post by SandaruLJ on May 26, 2018 21:25:42 GMT -5
Hi, It crashes (Unfortunately stopped) immediately after launching every time. Sometimes it will show the UI for a split second and then crash. Other times it's just a black screen before crashing. The first time however, after crashing, the scanning continued and finished. So I'd say the problem is with the UI. I'm running 6.0.1 (custom rom) in a Galaxy Note 3 (hlte). I had 340 dpi when I first launched it so I tried launching in 480 dpi (default for Note 3) but it didn't work either. However GMMP stayed about 5 seconds more this time before crashing. Anyway, thanks for your hard work man! GMMP is light years ahead of others. If you get crashes: Reproduce the crash then generate a logcat via the instructions here: gonemadmusicplayer.blogspot.com/2014/07/how-to-get-logcat-system-log-to-help.htmlaccording to the crash reports i've gotten (looks like its your device) the crash is something to do with the android audio effects. I'll try to get another update out today Updated to 3.0 alpha 1b. No crashes yet. |
|
|
|
Post by SandaruLJ on May 27, 2018 2:48:29 GMT -5
Bug detected! Looks like GMMP takes the values from m4a files and mp3 files separately in "GENRES" tab and places m4a files above mp3 files regardless of alphabetical order. It's racist behaviour  , but the thing that worries me the most is that this creates two entries of the same genre. Take a look at this: photos.app.goo.gl/wzCBmcGX5ZebZ2hH8 |
|
|
|
Post by Helmut on May 27, 2018 12:29:42 GMT -5
|
|
|
|
Post by GoneMAD on May 27, 2018 22:27:44 GMT -5
Bug detected! Looks like GMMP takes the values from m4a files and mp3 files separately in "GENRES" tab and places m4a files above mp3 files regardless of alphabetical order. It's racist behaviour , but the thing that worries me the most is that this creates two entries of the same genre. Take a look at this: photos.app.goo.gl/wzCBmcGX5ZebZ2hH8well its not exactly that.. the tag reader doesnt care what the file format is. I'd imagine the m4a and mp3 tags are stored differently. GMMPs database should be case insensitive now.. however that does not work for non standard characters. Could you send me one of the mp3 and one of the m4a that have the issue so i can take a look at their tags? |
|
|
|
Post by SandaruLJ on May 28, 2018 12:55:57 GMT -5
Bug detected! Looks like GMMP takes the values from m4a files and mp3 files separately in "GENRES" tab and places m4a files above mp3 files regardless of alphabetical order. It's racist behaviour , but the thing that worries me the most is that this creates two entries of the same genre. Take a look at this: photos.app.goo.gl/wzCBmcGX5ZebZ2hH8well its not exactly that.. the tag reader doesnt care what the file format is. I'd imagine the m4a and mp3 tags are stored differently. GMMPs database should be case insensitive now.. however that does not work for non standard characters. Could you send me one of the mp3 and one of the m4a that have the issue so i can take a look at their tags? You're right . It's something to do with how the tags are stored. (I tag my files with MusicBee) m4aTag Code: ©gen Single field, multiple values separated by ";" example: ©gen Grunge; Rock; Alternative mp3
Tag Code: TCON Multiple fields, each value in a separate field. example: TCON Grunge TCON Rock TCON Alternative |
|
|
|
Post by GoneMAD on May 28, 2018 13:13:27 GMT -5
well its not exactly that.. the tag reader doesnt care what the file format is. I'd imagine the m4a and mp3 tags are stored differently. GMMPs database should be case insensitive now.. however that does not work for non standard characters. Could you send me one of the mp3 and one of the m4a that have the issue so i can take a look at their tags? You're right . It's something to do with how the tags are stored. (I tag my files with MusicBee) m4aTag Code: ©gen Single field, multiple values separated by ";" example: ©gen Grunge; Rock; Alternative mp3
Tag Code: TCON Multiple fields, each value in a separate field. example: TCON Grunge TCON Rock TCON Alternative Here are the files : MEGAah yea. It was pointed out to me earlier today that when you have a genre or artist separated with a semi colon and a space afterwards ("; "), it does not trim off the space for the second entry. So it will appear in the database as " Artist" instead of "Artist". Should be an easy fix edit: in your case above, since the mp3 is using the TCON tag multiple times, gmmp's tag reader actually reads it as "genre1;genre2;genre3", so it doesnt have the extra space before the 2nd and 3rd genre |
|
|
|
Post by Helmut on May 29, 2018 3:20:31 GMT -5
The hilighted track in the queue is not the same as the currently playing song
|
|
|
|
Post by SandaruLJ on May 29, 2018 4:09:04 GMT -5
ah yea. It was pointed out to me earlier today that when you have a genre or artist separated with a semi colon and a space afterwards ("; "), it does not trim off the space for the second entry. So it will appear in the database as " Artist" instead of "Artist". Should be an easy fix edit: in your case above, since the mp3 is using the TCON tag multiple times, gmmp's tag reader actually reads it as "genre1;genre2;genre3", so it doesnt have the extra space before the 2nd and 3rd genre Alright. I'll re-tag my m4a files as "Genre1;Genre2;Genre3" for now, until you fix it. So the multiple genre problem is solved. Now to multiple artists. Situation 1: Single tag, multiple values example: TPE1 Steven Wilson;Ninet Tayeb Output: Both artists show up in the "ARTISTS" tab separately. Everything's fine! Situation 2: Multiple tags, single value in each example: just like the genre tags Output: One artist shows up in the "ARTISTS" tab, who doesn't even exist: "Steven Wilson Ninet Tayeb"  |
|
, but the thing that worries me the most is that this creates two entries of the same genre.