zane131 / mythrokuplayer Goto Github PK

This does tell the user that the player didn't go AWOL but it really isn't very informative. I found myself ignoring it and annoyed by it pretty quickly. It's also very tech-ese in language. The most common would be 404 and this could be interpreted with a message to say what was looked for was not found. otherwise, the http code would be helpful, if technical. Great idea, needs work. (imho)

There's some stuff we should look in to. it breaks for me and I don't think it should be merged.

PHP Warning: getimagesize(http://192.168.1.50/mythweb/data/video_covers/1904_20121226100900.mpg.png): failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found\r\n in /usr/share/mythweb/zane/MythRokuPlayer/mythroku/resizeimage.php on line 10

is followed by several video_* directory problems then it finally crashes

PHP Fatal error: Call to undefined function imagecreatefrompng() in /usr/share/mythweb/zane/MythRokuPlayer/mythroku/resizeimage.php on line 24
192.168.1.10 - - [26/Dec/2012:10:32:36 -0600] "GET /mythweb/mythroku/image.php?image=1904_20121226100900.mpg.png HTTP/1.1" 500 - "-" "Roku/DVP-4.9 (024.09E05060A)"

Recorded table does not have season, episode columns.

I scheduled a recording and was able to play it. I disabled the job type MetadataLookup in the global settings and using MythWeb I initiated that job. The recording is no longer included in the Playable list.

mythconverg.jobqueue has an entry for this recording and it's Type is not easily linkable to mythconverg.settings where, for example, jobAllowMetadata is unset. Complicating this problem is that Settings are distinguished by Hostname so a system of multiple recorders need to evaluate to the proper recording host (eg. not just any job<==>setting is accurate)

I'm not able to test the multi-resume and will assume that if one player resumes correctly then some other will also.

identified so far: contact Pete Neville about his willingness to promote a channel update with Roku; Then announce upcoming channel update to forum; Get Pete's feedback about the changes; Incorporate forum and Pete feedback; Identify beta testers (beta being Release Candidate upon which only critical issues force code changes); document remaining bugs and update README final; deploy.

tracking issue. first draft

suggest we resolve #17, #18, #20, #21 before contacting Pete. Need something pretty stable for him to evaluate.

a Feed::Item should allow a fully qualified path to a resource like sdimg

while rokuencode.sh is running the recording is listed and when the user tries to play it the system just returns with no warning or information.

it also affects the way previews are generated (they are not for this case)

when playing a recording, an HTTP request 404 for resource "File does not exist: /usr/share/mythweb/data/recordings..." which exists at '/DVR/1261_20121226065300.mp4'

recordings is a Storage Group location and may not reside in a relative filesystem. Default storage group is /DVR/recordings. Other locations might not be under DVR.

[Wed Dec 26 08:48:21 2012] [error] [client 192.168.1.10] File does not exist: /usr/share/mythweb/data/recordings
192.168.1.10 - - [26/Dec/2012:08:48:21 -0600] "GET /mythweb/data/recordings/1261_20121226065300.mp4 HTTP/1.1" 404 323 "-" "Roku/DVP-4.9 (024.09E05060A)"

I know there is some commentary about tweaking but this has changed since the last commit. it's about 5-10 seconds to far into the playback.

a symlink in mythweb/data to mythtv storagegroup Videos is req'd. I notice some/all of the storage group code removed that is on dev branch. This is not mentioned in the readme (already pretty intense reading) and would be worth fixing by looking up the location of Videos.

 [error] [client 192.168.1.10] File does not exist: /usr/share/mythweb/data/video   

press up while watching a recording. the menu does not present the "resume playing" option.

go up again to the listing of that recording then OK to select it, the menu now shows the resume option.

this may have been fixed but due to Issue #16 I can't try it. It would be a big problem in a channel release.

When I delete I'm returned to categories[0] in the main screen. I wish this was the top level menu instead, but... I press the Roku UP key and am presented with the detail screen of the show I just deleted. If I chose delete then some other show will unexpectedly be deleted.

after Delete we need to more carefully re-initialize internal data

recorded 4 shows in an empty system (no other recordings). no preview image files are created. no mythpreviewgen log file is created. no errors from httpd access/error or mythbackend logs

When I pick a top level like Recordings, the UI automatically jumps to the first sub-menu (title) item. To go to Date sorting I have to click UP. This is annoying because almost always I more want to select some other sub-menu before I want to select some item.

I can understand a personal preference but it probably breaks my backend flow. At the least there should be a setting to allow configuring between the drilling down or the shortcut to item behavior.

1. pic is not defined - xml_data.php line 637, can be removed.
2. add test for done to SQL in xml_data in checkPendingJobs() line 661

AND CAST(0x0100 AS UNSIGNED) > J.status

3. remove queryJobs.php
4. add (if necessary) to README install php-xml (for tests only I think?)
5. add to README warning to check jobqueue for errored jobs if playing some items is erratic..
6. suggest rokuencode as-shipped use iphone default; (much) faster and likely to work in broader cases

PHP Parse error: syntax error, unexpected T_ENCAPSED_AND_WHITESPACE, expecting T_STRING or T_VARIABLE or T_NUM_STRING in /usr/share/mythweb/git-zane/MythRokuPlayer/mythroku/mythtv_tv_del.php on line 45

dirname seems ok:

mysql> SELECT A.chanid,
-> A.starttime AS act_start,
-> B.starttime AS sch_start,
-> D.dirname
-> FROM recorded A
-> INNER JOIN recordedprogram B
-> ON A.programid = B.programid
-> LEFT OUTER JOIN recordedrating C
-> ON B.starttime = C.starttime AND B.chanid = C.chanid
-> LEFT OUTER JOIN storagegroup D
-> ON A.storagegroup = D.groupname
-> WHERE A.basename LIKE '1904_20130601055600.%';
+--------+---------------------+---------------------+------------------+
| chanid | act_start | sch_start | dirname |
+--------+---------------------+---------------------+------------------+
| 1904 | 2013-06-01 05:56:00 | 2013-06-01 05:00:00 | /PVR/recordings/ |
+--------+---------------------+---------------------+------------------+

recordings that are still being recorded are displayed to the user. The user is allowed to Delete them while recording is in progress. The status of the recording then is unchanged, the files are deleted, my HDHomerun continues to try to record. The mythbackend seems not to notice as I get nothing in mythbackend.log about it.

User jobs (like convert-to-mp4) that are running when the user deletes a recording are left running; HandBrake goes to 90% CPU usage. It did end cleanly after some time, afaict.

There are two real impact to the user: unexpectedly high cpu usage and recording channel that can't (easily) be re-assigned. They're both temporary That's good. They both decrease confidence. That's bad.

An obvious testcase would be deleting while mythtranscode. I need a much larger recording and hope to try that asap. i suspect mythbackend is resilient enough in this. hopes would be that mythrokuplayer was also...

I'll need some time to adapt my codebase to the new UI fields before we seek to promote this. This is just a tracking issue, assign to me if you like.

convert_datetime needs to return UTC if DBSchemaVer is 1307. It can be replaced with:

function convert_datetime($str)
{
        if(UseUTC)
                return convert_datetime_utc($str);
        else
                return convert_datetime_pre($str);

}

function convert_datetime_utc($str) 
{
        //function to convert mysql timestamp to unix time
        return strtotime( $str. ' UTC' );
}

function convert_datetime_pre( $str ) //mythtv  0.25
{
    list($date, $time)            = explode(' ', $str);
    list($year, $month,  $day)    = explode('-', $date);
    list($hour, $minute, $second) = explode(':', $time);

    if ( 0 == $year  ) { $year  = 1900; }
    if ( 0 == $month ) { $month = 1;    }
    if ( 0 == $day   ) { $day   = 1;    }

    return mktime($hour, $minute, $second, $month, $day, $year);
}

Not familiar enough with your use of convert_date so if it is given datetime from the new UTC data then it needs to be updated too.

[error] [client 192.168.1.50] Directory index forbidden by Options directive: /usr/share/mythweb/data/video_covers/

there is a link to video_covers in mythweb/data and its target is world writeable.

there are several other of the Videos housekeeping directories which are creating error_log web server entries

ls -a /usr/share/mythweb/data/
. .. cache recordings tv_icons video video_covers Videos

I recorded a program and unset the user job so that the file remained an MPG. It shows up in the Recordings menu and I can select to play it. It won't, of course, play but there is no indication of a problem cause, just that the play immediately returns.

While a recording is in progress, the program will also be presented like the above except that "NOT TRANSCODED" as added to the shows name in the display. For long show names this could be a problem and I'm not sure how useful it really is. My take is that I really only want to see playable recordings (unless the system lets me do something about it, like launch a mythtranscode and/or convert-to-mp4 job).

If mythtranscode has been run on the recording, there is no indication that the program should not play and the user is left with no feedback that the recording is not playable.