this issue is to reissue #40

[idontveapc]

#40

i was to reopen my issue (#40), but it can be done by the one who closes the issue/discussion. i didn't close it that's why opening a new.

the issue was as namida worked fine and didn't crash after updating. but the real issue was INDEXER.

• as said "INDEXER keeps running".

why im reopening a new; because:

• when updated from 1.4.8 to 1.5.4 and then to 1.6.8 the app didn't run indexer, until yesterday i re-index and what happened?? IT CRASHED (but after one crash it didn't crash again).
• then to test indexer i renamed(note: renamed in emoji glyphs and not in letter/text(s)) a song file. (note: the file was not in the /storage/emulated/0/Music directory instead another directory which namida indexed actually) namida asks for storage access AGAIN. and app crashes when you allow it then indexer runs and then when you open namida again you can't play the renamed file but the first song on the TRACKS (note: which is a song file .mp3/.m4a/.flac) is playing the song but showing a video without its original audio!! i believe that video was from my downloads though but audio was from the song file.
• now to fix the video problem, i had to clear the all data.(note: when i cleared data and when im testing, permission for storage is allowed and for all files) NOW WHAT?? version is 1.6.8 so i stupid believed it won't crash!? it crashed while indexer kept indexing and it's not a one crash. you can't use namida until indexer won't finish but namida is crashing. constantly.

now i had to go back to the version 1.4.8 and indexer finishes its job, namida doesn't crash. i can update namida now but there are a lot of ptoblems with indexing, and how new files would be added without running indexer again!!?

i think better would be to not extract meta like this, instead read the files and when they change.

[MSOB7YY]

hello, sorry for the inconvenience

the recent versions (starting from v1.4.8) implements a new way of indexing (5ae0247) which speeds it up by 250% using concurrent reading, this might be causing the crash.
im thinking about adding a flag to adapt the old behavior again, this could fix the issue completely

• about the second point, it's displaying the old track name/metadata because the indexing wasn't done, thus using the old file with old data, its also not playing audio bcz of the same reason (path changed but not updated in namida)

  • u can update by either a refresh or a full re-indexing

• its weird not being able to use namida while indexing, normally it should happen silently without affecting the experience, unless tags reading fails and switches to ffmpeg, this might cause some lag

• TO SUM THINGS UP:

  • if ur music is on sd card, the indexing might be even slower duo to low card read/write speeds
  • as for now, u can use Media Store API, which does not index anything, it just reads some ready values provided by android, so it will be instant
  • im not a fan of "restart ur machine" but "@Joeeeeb5" fixed a similar issue by restarting his phone lmao, u can try too

[Joeeeeb5]

You can also try excluding and reselecting the directory

[idontveapc]

my media files are on sdcard. on 1.4.8 indexer doesn't cause any crash or keeps running.

and a weird mention: the first still actually play a video (any video from my video files; it doesn't show the artwork of the album instead plays a video with audio of the track) after reinstalling to 1.4.8

[idontveapc]

updated description read again.

(because from the version 1.5.4 the INDEXER which INDEXES—i believe— didn't stop INDEXING, the app crashes and you open it again and INDEXER is INDEXING again, and what?? infinite loop of crashes!!!) the tracks are counted and even displayed (note: not all tracks are displayed on 1.5.4 which means indexer isn't indexing them alphabetically may be).

[idontveapc]

to test yourself; you can clear all data or reinstall version 1.5.4 or 1.6.8

[idontveapc]

yeah, on the build (from actions) namida indexes without constant crashing, but as soon as it indexes all it crashes once.

[idontveapc]

YUP! on the latest release namida indexes all the song and as it finishes~ in 1 or 2 secs it crashes.

[idontveapc]

LET GO THROUGH THESE TOO:

1. what's with indexing videos?
   

• they don'have their thumbnails .
  • as i reported already, the first song was actually a video's audio playing.

• i think cause of this is the font or its view size.
  • but rather, make the title to show above the text below.

[idontveapc]

the second screenshot again

[MSOB7YY]

thank you for detailed report, i think the indexing is working now?

• as for video get indexed as audio:
  • it's definitely cuz the file has an audio extensions, check

    namida/lib/core/constants.dart

    Lines 179 to 257 in 6104374

    	const Set<String> kAudioFileExtensions = {
    	'.m4a',
    	'.mp3',
    	'.webm',
    	'.ogg',
    	'.wav',
    	'.flac',
    	'.aac',
    	'.3gp',
    	'.ac3',
    	'.opus',
    	'.m4b',
    	'.pk',
    	'.8svx',
    	'.aa',
    	'.aax',
    	'.act',
    	'.aiff',
    	'.alac',
    	'.amr',
    	'.ape',
    	'.au',
    	'.awb',
    	'.cda',
    	'.dss',
    	'.dts',
    	'.dvf',
    	'.gsm',
    	'.iklax',
    	'.ivs',
    	'.m4p',
    	'.mmf',
    	'.movpkg',
    	'.mid',
    	'.mpc',
    	'.msv',
    	'.nmf',
    	'.oga',
    	'.mogg',
    	'.ra',
    	'.rm',
    	'.raw',
    	'.rf64',
    	'.sln',
    	'.tak',
    	'.tta',
    	'.voc',
    	'.vox',
    	'.wma',
    	'.wv',
    	'.aif',
    	'.aifc',
    	'.amz',
    	'.awc',
    	'.bwf',
    	'.caf',
    	'.dct',
    	'.dff',
    	'.dsf',
    	'.fap',
    	'.flp',
    	'.its',
    	'.kar',
    	'.kfn',
    	'.m4r',
    	'.mac',
    	'.mka',
    	'.mlp',
    	'.mp2',
    	'.mpp',
    	'.oma',
    	'.qcp',
    	'.rmi',
    	'.snd',
    	'.spx',
    	'.ts',
    	'.uax',
    	'.xmz',
    	};

• as for the miniplayer:
  1. you can swap artist & title places (from customization settings > miniplayer)
  2. currently the waveform resampler tries to keep some sort of normalization among all tracks, if the track has high samples it will cause it to get bigger like this, I'll look into another workaround for that

[idontveapc]

• it's indexing, yes, but still the crash...
• it's .mp4 😒

and this time I'LL close issue.

and waiting for playing the videos feature... not like this...

[MSOB7YY]

u might not notice but there is no way an mp4 video would get indexed along with audios, what may be happening here is that u have this video with split audio and video, for example

• macOs_Tips.mp3
• macos_tips.mp4

the audio will get indexed normally, and any related video will be picked and played along with the audio

[idontveapc]

.mp4 is a container with .avc(video) and/or .m4a container

[idontveapc]

funny indexing in new version...

• closed the app after fully indexing so assume at first it didn't crash
• but second one did just after indexing.

[MSOB7YY]

@idontveapc
u mean it crashed again?

[idontveapc]

yeah

[idontveapc]

v2.0.1 report:
Refreshing or refreshing library doesn't cause any crash. Haven't reindex yet, should i?

[MSOB7YY]

@idontveapc i want to say go ahead but im afraid more than you lmao
if it crashed, ur tracks should be still there

[idontveapc]

It didn't crash!! But application of colours from artworks is slow--ed?!

[idontveapc]

after restaring the app is not taking that long.

[MSOB7YY]

if u have artworks full res extracted (i.e u disabled media store and did a re-index) then it might be a bit slower to extract colors, but it only happens once.

anyways u restarted and everything is working fine, means i can take this as a "oki u can close issue now"? 😅