Trakt.tv LiveTV scrobble Development help request. (1 Viewer)

Alberto83

Portal Pro
August 7, 2012
336
108
Home Country
Italy Italy
Hmm..
@morpheus_xx I'm sorry to bother you again but i'm struggling on how to use the timeshiftcontexes list.
The problem is while i can access the list of all channels, there's no way to retrieve the offset and the tune in time (and the program).
After some trying i decided to debug it live and return the content of the list on the immediate window, and this is what i get:

Code:
_liveTVPlayer.TimeshiftContexes
Count = 2
    [0]: {GIALLO: unknown (Offset: 00:00:00, Tune in: 1/1/0001 00:00:00)}
    [1]: {TOPcrime: unknown (Offset: 00:00:00, Tune in: 1/1/0001 00:00:00)}

No matter what, the program just records the channel name, no program, and no offsets or tune in time. If i understood correctly, there's a list where you save channel + tune time where i can compare the current position to look exactly where i am in the stream, right?
Am i using it wrong? Looking to the wrong part?
 

Alberto83

Portal Pro
August 7, 2012
336
108
Home Country
Italy Italy
A little follow up.
I'm working on a little change on how TimeShiftContexes work on SlimTV, which also would be important to develop a fully working Trakt.TV scrobbler for LiveTV later.
The idea behind this is to transform the timeshiftcontexes list into a timeline for the current timeshift stream.
These are the features I've been able to code up to now, almost everything implemented under the SlimTVHanlder class.
  1. LiveTVMediaItem.TimeShiftContexes list as a timeline for the TimeShift. Every item in the list contains channel, tuneintime for the channel, program at the moment of tune with all its info (if any) and timeshift duration. This would make it easy to create a TimeLine Chapterlist for any timeshift player.
  2. A Thread.Timer process that triggers when CurrentProgram (if any) ends to add the next program to the list of timeshift. It resets every time a new channel is tuned, and sets back to the newly next program begin time.
  3. Distinctions between the timeline of the primary player and PIP player (all the logic was already there, I just took care not to break it).
  4. The whole process happens when the channel is already tuned, so zapping shouldn't add any unnecessary garbage.
  5. Since this implementation broke the chapter enumeration already implemented, I developed an IEqualityComparer class for the IChannel object to retrieve a list of unique channels using the Distinct() Method on the channellist. This way the current behavior of the Chapter selection is still working as before.
Next features ideas:
  1. I would like to implement a message system that notifies when a program changes that the trakt plugin (or any other plugin) can subscribe to and take proper actions.
  2. Implement a garbage collector to remove all the programs not tunable anymore because the timeshift is already past their seek point.
  3. Create a method seektoposition(positionInTimeshift) to switch back and forth the timeline and use programs as chapters. (I couldn't find it, but I haven't searched too much yet, focusing on bug bashing now)
With all these informations, a LiveTV Scrobbler for trakt TV would perform great, and take pretty precise decisions whether to scrobble a program or not based on what's inside the LiveTVMediaItem.TimeshiftContexes list. For example, it could decide not to scrobble a program because its tune time is too far away from the program start time, or because its timeshiftduration is not enough to consider the whole program as seen. Values could be manually changed in trakt plugin settings by users. Since I have the current timeline for the timeshift, I could also scrobble the current watching program, that might be different from the current program based on its properties. And zapping wouldn't be a problem anyways.

What do you think? Could this be a problem to other features?

And now, a little doubt that is puzzling me since I started this change: I'm currently developing all this client side, on the SlimTVClient. However, streams are "server side" objects. Would it make sense to do all this server side and then send it to the clients? This would make sense especially if clients could share streams, something that will be implemented in next TVE revisions, right?
 

morpheus_xx

Retired Team Member
  • Team MediaPortal
  • March 24, 2007
    12,073
    7,459
    Home Country
    Germany Germany
    This sounds really good (y) I'm really curious to see the code changes once your are done.

    Regarding the question of client vs. server side processing: I also thought about this topic before. Indeed it would be the best if the stream contain all the required information. "The stream" is a MPEG transport stream (.ts) written by the TV server using TsWriter, (optional streamed via rtsp) and then read on client by TsReader. Not sure if I remember correctly, but I think there are no "airing time" timestamps inside the stream? (I think there is many processing of timestamps by TsReader)

    They would be very helpful to have the playback position on client that matches the airing time. This would help to know the exact channel+time => program which is being played back. Otherwise there can be a mismatch if the user does pause the playback i.e. for 30 minutes and continues watching then. In this case the "airing time" is 30 min ahead of watching position.

    So a question to @mm1352000 and @Owlsroost: does the TS contain the required "airing time" information and is it available through TsReader?
     

    Owlsroost

    Retired Team Member
  • Premium Supporter
  • October 28, 2008
    5,540
    5,038
    Cambridge
    Home Country
    United Kingdom United Kingdom
    does the TS contain the required "airing time" information and is it available through TsReader?

    As far as I know - the stream does not contain any information about the 'airing time' (or any other EPG derived data/metadata), it's just a simple single-program TS with video, audio, subtitle, teletext and PSI (PMT, PAT, PCR) data.

    But @mm1352000 is the expert here on what could easily be added to the stream in TV Server. Parsing extra packets out of the stream in TsReader (e.g. a private stream) wouldn't be hard to add.
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    As far as I know - the stream does not contain any information about the 'airing time' (or any other EPG derived data/metadata), it's just a simple single-program TS with video, audio, subtitle, teletext and PSI (PMT, PAT, PCR) data.
    Correct.

    Adding that info into the stream would be annoyingly complex. It's not so hard for streams that already contain EIT (event information tables - standard DVB EPG source), but remember that not all streams contain that info. I imagine as many or more people use XMLTV, WebEPG, SchedulesDirect and other EPG sources. To pull EPG data out of the DB and inject it into the stream really would be a pain.
     

    morpheus_xx

    Retired Team Member
  • Team MediaPortal
  • March 24, 2007
    12,073
    7,459
    Home Country
    Germany Germany
    So there are no timestamps inside TS that can be used?
    How is the playback offset relative to timeshift buffer (LiveTV OSD) implemented inside MP1? Does it consider real times or only "position relative to nn seconds of TS buffer"?

    Besides this I have thought about the EIT, it could help here: the current/next program contain start+duration and program title (if present)
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    So there are no timestamps inside TS that can be used?
    There are no timestamps or markers that say "this is the start of a new program"/"a new program is starting now".

    How is the playback offset relative to timeshift buffer (LiveTV OSD) implemented inside MP1? Does it consider real times or only "position relative to nn seconds of TS buffer"?
    I don't understand the question. Probably it's a question for Owlsroost anyway.

    Besides this I have thought about the EIT, it could help here: the current/next program contain start+duration and program title (if present)
    Like I said: EIT is only available in some streams. If you design a system around that, it won't work for many (many many) people. In my opinion to do so would be a bad decision.
     

    morpheus_xx

    Retired Team Member
  • Team MediaPortal
  • March 24, 2007
    12,073
    7,459
    Home Country
    Germany Germany
    I googled around and found this Presentation timestamp - Wikipedia. It notes:
    The PTS is given in units related to a program's overall clock reference, either Program Clock Reference (PCR) or System Clock Reference (SCR), which is also transmitted in the transport stream or program stream.
    Could a "System Clock Reference" be used to calculate the timestamp?
     

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    SCR, PTS, DTS, PCR... none of them have any relation to programs (ie. TV programs), and so they cannot be used to detect when a new program starts. Rather, their purpose is for correct buffering and timing of video, audio and subtitle decoding and display.

    I repeat: there is nothing in the stream that can be used to detect when a new program starts.
    You can choose whether to believe me or not. :)

    P.S. Furthermore, TsWriter overwrites the PCR (and PTS and DTS?) to smooth them and [theoretically] enable TsReader to perform FF/RW and skip steps with less problems.
     

    morpheus_xx

    Retired Team Member
  • Team MediaPortal
  • March 24, 2007
    12,073
    7,459
    Home Country
    Germany Germany
    I repeat: there is nothing in the stream that can be used to detect when a new program starts.
    You can choose whether to believe me or not
    Probably a misunderstanding: I don't want to know "when" a new program starts (I have the full guide available), I only want to know the "time" of my current playback position.
    P.S. Furthermore, TsWriter overwrites the PCR (and PTS and DTS?) to smooth them and [theoretically] enable TsReader to perform FF/RW and skip steps with less problems.
    This is what I was referring to, that I thought there was some logic to deal with them.
     

    Users who are viewing this thread

    Top Bottom