abhay123lp / tunesremote-plus

Automatically exported from code.google.com/p/tunesremote-plus
0 stars 0 forks source link

Time total/elapsed/remaining is 30 minutes over #68

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Q. What Android hardware device do you own?  (HTC Hero, Samsung Galaxy,
etc)

A: Samsung Galaxy S2

Q. On what Android operating system version? (2.1, 2.2, Honeycomb 3.0.1
etc)

A: 2.3.3

Q. What DACP server, OS, and version? (OSX iTunes 10.1.2, Windows 7
MonkeyTunes 1.5.1 etc)

A: Windows 7 64bit, iTunes 10.3.1.55

Q. What TunesRemote+ version? (found on Menu->More->About)

A: 2.4.0 (Is this really on the about screen?  I just get the big disclaimer 
but couldn't find the ver.)

Please provide any additional information below.

When picking tracks, track times show as 30 minutes longer than they really 
are.  The same occurs for elapsed/remaining times shown when playing.

Screenshots attached.

Original issue reported on code.google.com by lukerossrobinson on 7 Jul 2011 at 7:19

Attachments:

GoogleCodeExporter commented 8 years ago
Hmmm another user reported this same issue.

http://code.google.com/p/tunesremote-plus/issues/detail?id=52&can=1&q=timing

I have never been able to reproduce it.  But his issue was exactly like yours 
adding the 30 minutes to everything.   

Can I ask what Country your Android device is set to?  I am thinking maybe it 
has to do with internationalization and screwed up formatting of the timing.

Original comment by mellowaredev on 7 Jul 2011 at 11:05

GoogleCodeExporter commented 8 years ago
Ah OK, I did a quick search because I thought surely I wouldn't be the only one 
to notice this, but I was searching for time not timing...

Phone is set to English (Australia), iTunes is set to English (United Kingdom).

Initially I was thinking the same thing but from my quick read of the protocol, 
times are sent in ms?  So I didn't really see why anything would be adding 
1800000 to the value.

Original comment by lukerossrobinson on 7 Jul 2011 at 11:15

GoogleCodeExporter commented 8 years ago
YEah so what is fishy is here is what the code is essentially doing...

SimpleDateFormat format = new SimpleDateFormat("m:ss");
Date date = new Date(0);
date.setTime(resp.getNumberLong("astm"));
final String length = format.format(date);

So it is essentially setting the ASTM value from iTunes which is in 
milliseconds to a Date field.  then doing a Date formatter for Minutes:Seconds 
on it.   There must be some flaw in this logic for certain users that both you 
and another user would have this issue but myself and others do not.

Original comment by mellowaredev on 7 Jul 2011 at 12:52

GoogleCodeExporter commented 8 years ago
OK can you try this BETA and see if it fixes the +30 minute issue?

http://code.google.com/p/tunesremote-plus/downloads/list

Original comment by mellowaredev on 7 Jul 2011 at 2:04

GoogleCodeExporter commented 8 years ago
Yep, that did the trick!

Original comment by lukerossrobinson on 7 Jul 2011 at 2:43

GoogleCodeExporter commented 8 years ago
OK so all i did was change to this function to calculate the time rather than 
using the Date field.

   public static String convertTime(long milliseconds) {
      final int seconds = (int) ((milliseconds / 1000) % 60);
      final int minutes = (int) ((milliseconds / 1000) / 60);
      return String.format("%d:%02d", minutes, seconds);
   }

So my theory was that for some reason in your Date area is your GMT offset 
somehow by 30 minutes or something strange like that?   

Original comment by mellowaredev on 7 Jul 2011 at 2:54

GoogleCodeExporter commented 8 years ago
Ahhhhh, yeah, good guess.  I'm UTC+09:30, because we like to be different down 
here.
Mystery solved.

Original comment by lukerossrobinson on 7 Jul 2011 at 2:58

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
Tested as well with changing the times and seems to work just fine. No problems 
on other features with the changes, so can be put into the next release.

And yea taking the direct time from the system rather then converting it to a 
common time sure would have been also my guess on this problem.

Original comment by cramermaurice@gmail.com on 18 Jul 2011 at 8:05

GoogleCodeExporter commented 8 years ago
Released on Android Market v 2.4.1

Original comment by mellowaredev on 24 Aug 2011 at 8:41