If it’s on GitHub it’s somewhat approved but still it needs someone willing to implement it.
Implementation are the Pull Requests (PR) which have to be reviewed and approved before being merged to code.
To sum it up : this forum is (in part) to avoid to overwhelm GitHub issues with issues already existing or which won’t be accepted. Besides it’s also a way to discuss about it and try to keep issues as clean as possible for a potential developer.
If you are interested in an issue you have to follow it on Github to be notified when there is some new info about it.
Well explained - thanks!!!
I just uploaded the update. Might take a few hours for Google to review it.
Beta2 updated. Local folder automatic refresh now working - thanks!
Rather than just using the Beta for finding glitches, as important as that is, it can also be used as an “acceptance test” for new features. Other than the “Show Remaining Time” option, are there other new items that can be tested? I realize that many changes may not be testable as they involve compatibility or efficiency issues, or specific bug fixes that don’t affect all users.
This may - or may not - be Beta related. It is confusing and difficult to explain so please first refer to the attached screenshots.
Screenshots Playing & Queue, were taken at the same time while paused listening to an episode - the time left shown on them are different - and negative! The times shown on the widget are: 0:52:13 / 0:50:16 is consistent with the times shown on the Playing screenshot. Note that the total duration is less than the time played! I also have a screenshot of the widget but as it is on my phone’s home page for privacy reasons I don’t wish to post it, however I can email it to @bytehamster along with the url of the podcast if requested.
The screenshot Episode is consistent with the Queue screenshot - it is the episode as shown in the subscription taken after I finished the episode itself and it was deleted. I did not time my actual listening - but I believe that it was just over an hour.
I paused various times while listening to this episode, and also rewound on occasion using both my Bluetooth earphone’s and the screen’s button. Also, what I suspect may be the cause, while pausing I listened to another podcast (a news bulletin) and then returned to this one. On returning I seemed to have been further forward in the episode than where I left off, and I used the time bar on Playing to rewind. It was then that I noticed that the time left was incorrect.
I suspect that this may have also occurred to me about a month ago (ie before the Beta version) - I remember noticing the play time on the widget greater than the total duration, but I then disregarded it. In a quick search through the forum I have not seen a similar problem described.
I hope that I have been sufficiently clear in my description. Please advise if you need further info and/or if I should move this over to the Bug category.
@DavidDez your bug looks like it might be caused by my pull request to show the remaining time on a podcast.
You can activate this via the preference ( User Interface) or tapping on the time on the bottom right in the playing screen.
Does it happen only this particular podcast or others?
Thanks for joining in @tonytamsf. It’s an honour!
What you suggest is the cause is certainly possible - I did turn on the new option in the Beta 2.2 settings. Also, prior to it being an option, I had tapped on the time as you described in the production version 2.1 - so it may be a factor in what may have happened to me before.
No - that’s my only example. I am limited in free time but nonetheless will keep an eye out on my time bar while listening in general and will also try to recreate various scenarios and see if I can cause the problem to re-occur.
Sometimes (when episodes do not specify the duration in their headers and use variable bitrate encoding), AntennaPod has to guess the total duration based on file size. There are some cases where it is not 100% accurate and the playback position gets more than the duration. I think in this case, it would be good to just set a remaining time that is <0 to 0.
Thanks @bytehamster (BTW - what a wonderful nom de plume!). I had thought that a variable bitrate might be a cause. And yes, in those cases making <0 into 0 (and I assume when total duration is shown, like in the widget, to make it equal to the played time) would be less confusing to the listener. Would this cause a problem with the “Smart Marked as Played” option?
Although this makes sense, was the bitrate and lack of header the problem in my specific case? Perhaps there are other causes (or co-causes) like the change @tonytamsf cited or my thought about having paused, rewound and played another episode during the pause. I’ll try to test the latter.
I notice on the “What’s New” in Google Play for Beta “Optional rewind, forward & skip buttons on widget” is listed - that is @tonytamsf’s Widget improvement, which is also on GitHub.
I don’t see it in settings - is it my old eyes, am I missing something or was it listed but not in the current Beta2 version and will be in a later one?
The settings are shown when adding the widget
Thanks - have now deleted the old widget, put in the new - Looks Great!!
I had jumped to the wrong conclusion on how it was implemented. Perhaps best that I shouldn’t test new features in the Beta and keep myself centred noticing any problems that may come up!
@DavidDez I find it useful for this type of acceptance testing for the releases, beta and production so users can find out what has been released as well as how they can adopt it.
It is useful for me as a developer to see how the features are adopted as well as bugs with the new changes
The fix for this is here, thanks for reporting
Thanks @tonytamsf - therefore to improve the adoption of the new widget feature, I suggest that the “What’s New” in Google Play should say something like “To adopt the new widget features delete the old and re-install”
I see your point @DavidDez about the instructions in the ‘What’s New’, but unfortunately the number of characters for these pieces of text is limited to 500 characters. Getting to a text that includes the main points and is not too long is a struggle
Just to note that 2.2.0 is now out of Beta and installed - I didn’t even notice until now - shows how good and seamless the acceptance and installation went! CONGRATULATIONS to @ByteHamster @tonytamsf @keunes @Matth78 and all involved! I guess this discussion can now be flagged as a “Solution”!
2.2.0 is currently rolling out to 100% of the beta testers and to 5% of the normal users
I guess I jumped the gun - but CONGRATS still stand on a job well done.