[TIMOB-16102] iOS: AudioPlayer progress event not firing
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Medium |
Status | Closed |
Resolution | Invalid |
Resolution Date | 2016-05-14T19:46:38.000+0000 |
Affected Version/s | n/a |
Fix Version/s | n/a |
Components | iOS |
Labels | n/a |
Reporter | Mark Burggraf |
Assignee | Angel Petkov |
Created | 2011-11-04T13:30:25.000+0000 |
Updated | 2016-05-14T19:47:04.000+0000 |
Description
The "progress" event is not firing on the AudioPlayer object. This event fires in 1.8.x versions of Titanium Mobile, but not in 1.7.3 through 1.7.5.
Please cancel this report. The issue is in some related code, but not in the event firing section. Sorry.
Maybe don't cancel it -- the issue is that the progress event is firing a different value between 1.7.x and 1.8.x. In 1.7.5, it fires e.progress = 1.0 to mean one second has passed. In 1.8.x, it fires e.progress = 1000.0 to mean one second has passed.
Thanks for raising this ticket, Mark. In order for me to escalate it to the core team, all the fields must be complete. Please check it against the [JIRA Ticket Checklist](https://wiki.appcelerator.org/display/guides/How+to+Submit+a+Bug+Report#HowtoSubmitaBugReport-JIRATicketChecklist), and add any missing information. Furthermore, a test case must run without modification, as per the [Creating a Test Case](https://wiki.appcelerator.org/display/guides/How+to+Submit+a+Bug+Report#HowtoSubmitaBugReport-CreatingaTestCase) section. I will close this for now. Please reopen it once it is complete, and I will move it to the main project. Cheers
Paul, I came to open a ticket about this very issue and found this one. The following were logged from inside the 'progress' event handler of an AudioPlayer: {noformat} AndroidMediaPlayer.addEventListener('progress',function(e){ Ti.API.info('EAC LOGGING: Progress: '+e.progress); }); {noformat} 1.8.0.1 V8 Streamed MP3 12-29 20:10:57.580: I/TiAPI(432): EAC LOGGING: Progress: 575 12-29 20:10:58.570: I/TiAPI(432): EAC LOGGING: Progress: 1019 1.8.0.1 Rhino Streamed MP3 12-29 21:12:31.428: I/TiAPI(1577): EAC LOGGING: Progress: 549 12-29 21:12:32.358: I/TiAPI(1577): EAC LOGGING: Progress: 967 1.7.5 Android Streamed MP3 12-29 21:23:15.278: I/TiAPI(5561): (kroll$3) [2791,35513] EAC LOGGING: Progress: 0.549 12-29 21:23:16.267: I/TiAPI(5561): (kroll$3) [998,36511] EAC LOGGING: Progress: 1.019 iOS suffers from a similar problem with currentPlayBack time and the VideoPlayer.
Hi Paul, Sorry, but if you close out bugs because the (volunteer) reporter didn't write a complete test case for you, I think you're doing your users a disservice. A bug is still a bug, whether or not the person reporting it does as complete a job as you'd like. I'm a programmer, so I completely understand that it's impossible (and a waste of time) to try to fix items that can't be duplicated or explained, but stuff like this is very cut-and-dried. As a programmer, I'd be able to fix this in a single line of code. One version of the sdk is reporting seconds, the other is reporting milliseconds. Not rocket surgery. Mark
Mark, These values are reminiscent of the 1.6.0 problems where the Android and iOS values were not the same, requiring platform specific mathematics to even them out. I'm with you in that this is a quick code fix on our end. But if I hack in a fix for this, I can't easily just compile against 1.7.5 for comparison any more.
Well, it's a simple point. It's now broken. It either needs to be fixed, or documented that 1.8 is different than 1.7 and that anyone using this API needs to change their code or expect really screwy results.
Mark I understand that the process may be frustrating for senior community members who are familiar with the bug reporting process of numerous other projects. However, I hope you can appreciate that Titanium has a very large userbase with a wide range of experience levels. We accept and appreciate reports from our whole community but, as a consequence, tickets are continually being raised with differing levels of accuracy. This ticket is a good example. The original problem was, "AudioPlayer progress event not firing", with no test case provided. It could take considerable time to prove this, particularly if there are other factors involved; either a combination of Titanium object properties, contexts, or some user coding issue. It was good of you to update the ticket, but many people do not. We just don't have the resources to chase bugs that may or may not exist. Also, as [Creating a Test Case](https://wiki.appcelerator.org/display/guides/How+to+Submit+a+Bug+Report#HowtoSubmitaBugReport-CreatingaTestCase) explains, a test case can often reveal the cause of a problem when it's a user issue. Note that, in this instance, I have raised tickets TIMOB-6941 and TIMOB-6942 to address the remaining issues you describe. Thank you for your understanding and patience with the process in future. Cheers
Thank you for your update, Stephen - it was very helpful! :)
Paul -- I understand. This ticket isn't about what I originally reported, you're right. I should have opened a separate ticket for this to avoid confusion. Sorry.
PR: https://github.com/appcelerator/titanium_mobile/pull/7974 Demo code:
Failing review. The provided test case that did not work did not work beause the event listener was placed after the audio player starts. [Fixing it](https://gist.github.com/hansemannn/5c9c5d40ba175233783c623f68e54ac9) makes the player work properly. Regarding the seconds/milliseconds discussion: The docs state milliseconds as the right measurement for 5+ years now. If anyone has objections, please let me know, but as this works, we should not attempt core-changes here.