"Play" recording fails

[GoogleCodeExporter]

Which version of MythDroid were you using?
0.6.2

Which version of MDD?
0.6.2

Which version of MythTV were you using? (e.g. mythfrontend --version)
MythTV Version : 0.25.2-2.fc17 (v0.25.2-15-g46cab93)
MythTV Branch : fixes/0.25

What steps will reproduce the problem?
1. Go into recordings
2. Select recording
3. Press Play

What is the expected output? What do you see instead?

Expected behaviour is to play the recording that I selected. Instead, the 
"Watch Recordings Screen" appears on the frontend for a brief second and then 
goes back to the main menu. The recording does not play. In mythdroid,the main 
remote appears and a dialog box says "Loading" this goes away and bring me back 
to the main menu after about 1-2 seconds.

Let me know what additional info I can provide to help solve this issue.

Thanks

Original issue reported on code.google.com by pythe...@gmail.com on 13 Oct 2012 at 4:20

[GoogleCodeExporter]

Hi, we'll need logs from the device to diagnose. You can retrieve these using 
adb (adb logcat) or using an app from the market (search for logcat). The 
relevant bit of the device log should make it clear what's going wrong - could 
you attach that to this ticket please? 

Original comment by foobum on 14 Oct 2012 at 3:31

[GoogleCodeExporter]

I didn't attach the entire log (it is huge) but I think I grabbed the relevant 
sections.

Looks like this command is causing some problems.
D/ConnMgr (14727): writeLine: play prog 1081 2012-10-12T00:30:00
D/ConnMgr (14727): readLine: ERROR: Could not find recording for chanid 1081 @ 
2012-10-12T00:30:00

Original comment by pythe...@gmail.com on 14 Oct 2012 at 5:32

Attachments:

• mythandroid-log.txt

[GoogleCodeExporter]

Looking into the issue a bit further it appears that the times listed on the 
recordings are in UTC and this is what is being passed to the play prog 
command. However, the timestamps on the database are 5 hours behind (EDT). If 
adjust the timestamp in the above command "play prog 1081 2012-10-12T00:30:00" 
to "play prog 1081 2012-10-11T20:30:00" everything works as expected.

Should mention this is a Galaxy Nexus running Jellybean 4.1

Original comment by pythe...@gmail.com on 14 Oct 2012 at 5:57

[GoogleCodeExporter]

The date passed to the frontend should be in your local timezone. We recently 
added some code to set the local timezone to that of the backend (rather than 
that of the android device) - this makes things work if your device is in a 
different timezone to your backend. But, it also means that things will break 
if your backend timezone is incorrect. What's your timezone set to? ($ cat 
/etc/timezone).

Original comment by foobum on 15 Oct 2012 at 3:45

[GoogleCodeExporter]

As far is I know the timezone is set correctly on the system. I do not have 
/etc/timezone, but I do have /etc/localtime

[root@m2n ~]# ls -l /etc/localtime 
-rw-r--r-- 1 root root 3519 Jan  1  2012 /etc/localtime

[root@m2n ~]# file /etc/localtime
/etc/localtime: timezone data, version 2, 4 gmt time flags, 4 std time flags, 
no leap seconds, 235 transition times, 4 abbreviation chars

[root@m2n ~]# cat /etc/sysconfig/clock 
# The time zone of the system is defined by the contents of /etc/localtime.
# This file is only for evaluation by system-config-date, do not rely on its
# contents elsewhere.
ZONE="America/New York"

How is the timezone being acquired from the backend?

Original comment by pythe...@gmail.com on 15 Oct 2012 at 10:29

[GoogleCodeExporter]

It's acquired using the QUERY_TIME_ZONE mythtv protocol message..

I've attached a little perl script that you can use to see what the backend 
sends. Just do perl tz.pl <hostname or IP address of backend> and post the 
output.

Original comment by foobum on 15 Oct 2012 at 10:57

Attachments:

• tz.pl

[GoogleCodeExporter]

tux:~ $ nc m2n.leap.lan 6543
30      MYTH_PROTO_VERSION 72 D78EFD6F 23     ANN Playback hostname 1   15   
QUERY_TIME_ZONE       4DONE

13      ACCEPT[]:[]72
2       OK
97      BACKEND_MESSAGE[]:[]SYSTEM_EVENT CLIENT_CONNECTED HOSTNAME hostname 
SENDER m2n.leap.lan[]:[]empty
51      America/New York[]:[]-14400[]:[]2012-10-15T19:04:01
read(net): Connection reset by peer

The time return is the correct time in the correct timezone

Original comment by pythe...@gmail.com on 15 Oct 2012 at 11:05

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks for the script, much easier :)

tux:~ $ perl /tmp/tz.pl m2n.leap.lan
--> 30      MYTH_PROTO_VERSION 72 D78EFD6F
<-- 13      ACCEPT[]:[]72
--> 22      ANN Playback android 0
<-- 2       OK
--> 15      QUERY_TIME_ZONE
<-- 51      America/New York[]:[]-14400[]:[]2012-10-15T19:07:55

Original comment by pythe...@gmail.com on 15 Oct 2012 at 11:08

[GoogleCodeExporter]

Hm.. The problem is that, according to java, your timezone should be called 
"America/New_York". I guess a $tz =~ 's/ /_/g' might do it. 

Original comment by foobum on 15 Oct 2012 at 11:28

[GoogleCodeExporter]

This issue was closed by revision r811.

Original comment by foobum on 15 Oct 2012 at 11:35

• Changed state: Fixed