I noticed that the Netflix app shows a progress bar for how much of the episode has been watched so I hacked something similar into PlexConnect and was hoping to get some feedback.
Any thoughts?
I noticed that the Netflix app shows a progress bar for how much of the episode has been watched so I hacked something similar into PlexConnect and was hoping to get some feedback.
Any thoughts?
Interesting.
What's the requirement on aTV iOS version?
Interesting.
What's the requirement on aTV iOS version?
hmm, I'm not sure. I only have access to an Apple TV running the current 6.0 software. It uses the XML tag in the accessories area of Episode.xml.
Any chance of a screen where the progress bar is only shown for partially watched episodes?
I have a feeling it might look much cleaner.
I was just about to post the same thing: I think it should only be present on partial-watches.
Also wondering how well it handles long episode names — do they get an ellipsis? or scroll? or just cropped?
Neat idea, though!
Any chance of a screen where the progress bar is only shown for partially watched episodes?
I have a feeling it might look much cleaner.
I was just about to post the same thing: I think it should only be present on partial-watches.
Also wondering how well it handles long episode names — do they get an ellipsis? or scroll? or just cropped?
Neat idea, though!
The name gets truncated with an ellipsis when it's not highlighted and then switches to scrolling when the cell is highlighted.
Those also contain the change to only show the progress on partially watched episodes.
Here's a link to the effected code for the original post with the progress bar on any viewed cell.
https://github.com/tallerthenyou/PlexConnect/commit/619428239ef6547f8e74aa43e9818e71dbd0e86b
The change to make them show up on only in-progress episodes is pretty trivial.
Looks great. I think it'd be a decent addition to the main branch.
It is also iOS 6 only so a bit more complex to add cleanly into any code that is compatible with earlier firmwares.
Ahhh, okay.
It is also iOS 6 only so a bit more complex to add cleanly into any code that is compatible with earlier firmwares.
Is there a CUT command or something to exclude code based on iOS version?
Something along those lines will have to be used.
Is there anything in place to make that possible currently?
Is there anywhere in the current code that the XML is modified based on which version of iOS is being used?
Nope, it's not in there yet... everything's the same.
Nope, it's not in there yet... everything's the same.
I added some code to only support modifying the tree based on iOS version and added it to the progress bar (in a different commit).
https://github.com/tallerthenyou/PlexConnect/commit/d11a5ae048c06d3371e6b112458fe680c9d11edd
What do you think?
Something like this. Though I don't like this highly specialized approach:
- getting the iOS version from the http header is - I guess - the right thing to do.
- adding it to the X-Plex-Options for PMS requests gives it a nice touch. :-)
- MIN_OS( ) should (in my opinion) just fade into the existing CUT( ). There are a couple of variable sources already baked into getKey(): # internal variables, $ aTV settings, % PMS properties. I guess we could add something like aTV Properties as well, to keep it future-proof. :-D
- similar with your initial function getPercentComplete( ). I wonder if we want to implement something like a basic math function, basically a mixture of VAR( ) and EVAL( ), accepting more than one parameter...
Something like this. Though I don't like this highly specialized approach:
- getting the iOS version from the http header is - I guess - the right thing to do.
- adding it to the X-Plex-Options for PMS requests gives it a nice touch. :-)
- MIN_OS( ) should (in my opinion) just fade into the existing CUT( ). There are a couple of variable sources already baked into getKey(): # internal variables, $ aTV settings, % PMS properties. I guess we could add something like aTV Properties as well, to keep it future-proof. :-D
- similar with your initial function getPercentComplete( ). I wonder if we want to implement something like a basic math function, basically a mixture of VAR( ) and EVAL( ), accepting more than one parameter...
I put something together as a potential replacement for EVAL. The biggest change is that I made it possible to pass one {{...}} element into another {{...}} element as a parameter by making sure that the number of opening and closing brackets matched up in ExpandLine and ExpandNode.
I called my new function MATH for simplicity of testing, but ideally I think it would replace EVAL.
With MATH my previous getPercentComplete function can be replaced with {{MATH({{VAL(viewOffset:0)}} * 100 / {{VAL(duration:1)}} )}}
Here's a link to the commit with my changes:
https://github.com/tallerthenyou/PlexConnect/commit/8a768d877ee79503ea489cecfa3e3ab4c5f1aea7
Feedback is very welcome.
- MIN_OS( ) should (in my opinion) just fade into the existing CUT( ). There are a couple of variable sources already baked into getKey(): # internal variables, $ aTV settings, % PMS properties. I guess we could add something like aTV Properties as well, to keep it future-proof. :-D
- similar with your initial function getPercentComplete( ). I wonder if we want to implement something like a basic math function, basically a mixture of VAR( ) and EVAL( ), accepting more than one parameter...
I threw this together too as a starting point for discussion on how to accomplish MIN_OS in a more general way:
https://github.com/tallerthenyou/PlexConnect/commit/9e67f606e93ed11f8a68fde09076f2d42e71a442
The result is pretty cluttered, but it's at least something to work from potentially.
I'd love to hear your thoughts
>>I put something together as a potential replacement for EVAL. The biggest change is that I made it possible to pass one {{...}} element into another {{...}} element as a parameter by making sure that the number of opening and closing brackets matched up in ExpandLine and ExpandNode.
That is a nice one. We were looking for something similar a couple of times, but never could decide to actually do the work and implement it. Great piece of coding!
>>https://github.com/t...076f2d42e71a442
>>The result is pretty cluttered, but it's at least something to work from potentially.
For CUTting the lines away, I don't think that you actually need to do the comparison in MATH. If you have the version string - your "Platform" something - you can actually use the CUT directly (syntax: CUT(key:dflt:conversion)).
It should work similar to this:
{{CUT(^aTVversion:CUT:=CUT|6.0=)}}
Doesn't look intuitive, I know. It's grown :-)
What it should do:
- it takes the string behind the key (in our case '6.0.2' or so).
- if this key/variable is not there we will default to CUT and proceed with cutting
- otherwise it will be converted: the left hand operands ('', '6.0') will be sorted, the aTVversion checked against it and the highest possible value is taken. Kind of like a characteristic curve without interpolation and based on strings...). So everything "smaller" then 6.0 will be 'CUT', everything else ''.
The result of this (key, dftl, conversion) is checked against None, '', 0, False, I don't know... if it's True (that is not one of the former typed values) we will proceed with the cutting operation, thus I like to set it to CUT. It gives a hint what is going to happen.
Again, I haven't tested that in real life, but from my experience it should work along those lines...