Write chunk size property not observed

[fillobotto]

Actually you can set write chunk size in TagOptionSingleton: https://bitbucket.org/ijabz/jaudiotagger/src/0ed2680e56c77b7a6d4a89b92951aff1cc1df6d8/src/org/jaudiotagger/tag/TagOptionSingleton.java?at=master&fileviewer=file-view-default#TagOptionSingleton.java-347

But here the property is ignored and it is set to 10MB: https://bitbucket.org/ijabz/jaudiotagger/src/0ed2680e56c77b7a6d4a89b92951aff1cc1df6d8/src/org/jaudiotagger/tag/id3/AbstractID3v2Tag.java?at=master&fileviewer=file-view-default#AbstractID3v2Tag.java-88

This was problematic in my application, in fact often the bytes transfer between streams resulted in loss of some bytes. Shouldn't the singleton property observed also in AbstractID3v2Tag.java?

[IJabz]

HI, I agree it should use this preference. But I dont undserstand why you are losing bytes, seems like a hardware error Does it trigger an exception since there is this code

                if (written2 != audiolength)
                {
                    throw new RuntimeException(ErrorMessage.MP3_UNABLE_TO_ADJUST_PADDING.getMsg(audiolength, written2));
                }

[fillobotto]

Of course it does, but it could be interesting why trasferTo and transferFrom methods are not copying all the byes in one shot.

I thought that it may be because of low available resources and process killing in Android systems and I hope that doing the same process in smaller​ chunks could solve the problem.

As you said, the exception is correctly triggered so it's all right but I wanted to point this thing out opening a minor issue.

[IJabz]

Actually now I think of it I have seen an error about adjusting padding occur from time to time, but I never understood why it occurred.

[IJabz]

Perhaps we need a retry mechanism ?

[fillobotto]

Inside my application I'm using similar code (for simple file copy, not jaudiotagger related). I decided to save the number of transferred bytes inside a temp variable that, at every chunk cycle, is used as transferTo offset parameter and is summed to the returned amount of the transferTo method. The cycle continues since the temp variable is minor that the total amount. Doing so, if some byes are not copied during a cycle, they will be in the next one. BUT I don't know if this logic can cause infinite loops because I don't know the reason behind all of this.

UPDATE: I distributed a beta version of my application using a buffer of 16kb instead of 10Mb and will let you know if the exception is still there or increased/decreased. Writing performance seems not to be affected though.

UPDATE 2: this partially solved the issue and seems it happens with a lower incidence.

[IJabz]

This should now be resolved by the changes we made to mp3s so we now shift the data within the file using ShiftData class