+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: PVR Development (/forumdisplay.php?fid=136)
+--- Thread: New MythTV add-on using libcmyth (/showthread.php?tid=110694)
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207
- orduek - 2011-10-20 22:04
As I understand it - mythtv backend just records every time you watch livetv, hence you have a recorded file so you can "dump" it from the player and "take" it back again.
Needs to see how mythfrontend do it, I think its handled in the Backend side.
- tsp42 - 2011-10-20 22:05
dushmaniac: Timeshift is implemented in the backend. MythTV treats the liveTV as just another recording. I've implemented the ReadLiveStream, SeekLiveStream, OpenLiveStream and CloseLiveStream in the add-on and set the pCapabilities->bSupportsTimeshift to true. So the LiveTV should ideally be treated as a normal recording + the recorder button (that just keeps growing). Could you give a hint where I should look to enable this functionality in the PVR code. I guess the meaning of the bSupportsTimeshift is that the backend takes care of the timeshifting? If that is the case shouldn't it be safe to enable timeshifting for this scenario in the PVR code?
- tsp42 - 2011-10-20 22:12
Jimmer Wrote:I know there should be a single issue per post, but I'm also wondering if resume on playback will be implemented in the plugin or if this is a limitation of libcmyth or the pvr-branch in general (or both?)....It is a limitation of the pvr-branch. See issue 273
Oh well back to bug hunting
- tsp42 - 2011-10-20 22:58
Jimmer Wrote:Sure, I meant the off by one hour issue - sorry for not being clearer!I tried setting my timezone to America/Managua instead of CET and I can confirm that the timeline view is messed completely up so it is something wrong with the timezone code in the PVR code. In addition I can reproduce the empty EPG data after resetting the PVR database although XBMC doesn't crash.
The issues I have with missing epg data are:
1) in the epg:Channel view. I get "No EPG entries".
2) When I switch to epg:Now view I have data for some channels, but other channels (BBC2, ITV, for example) are actually missing from the view altogether. Not lacking epg data, but not actually present.
3) When I switch to epg:Next all channels are present and all have epg data. Although it is mostly what's actually on now.
4) When I switch to epg:Timeline sometimes it is correct, sometimes (on some channels) epg entries are merged so that some programs appear to start earlier than they should (i.e. by one hour). However if I select said program, the info box that pops up shows the correct show start and finish times.
5) If I come out of epg view and go into "TV Channels" view, then I have epg info for the the channels I described as present in (2) above. All channels missing in (2) above are shown in this view, but display "No Information Available"
But other than that epg works perfectly! Seriously though, I really only use timeline view - just like on a normal TV or PVR, so this is the only issue that really worries me. But I have a feeling that they are all linked by the timezone thing (mostly due to the fact that what's on next shows up, whilst what's on now doesn't).
Jimmer
- fiveisalive - 2011-10-20 23:39
tsp42 Wrote:I tried setting my timezone to America/Managua instead of CET and I can confirm that the timeline view is messed completely up so it is something wrong with the timezone code in the PVR code. In addition I can reproduce the empty EPG data after resetting the PVR database although XBMC doesn't crash.
Thanks! Phew, glad I'm not the only one to see this. Were you resetting just the EPG or PVR database or both? I can reproduce the problem, with resetting the EPG database only.
Incidentally the XBMC crashes I saw previously when resetting the EPG database typically only happened when I had set it to get 10-14 days worth of data, not just 1-2 days. And with the larger number of days set, the CPU usage went up hugely, so I suspect that probably that's more an issue with how well sqlite and xbmc can handle writing to the database rather than being related to the timezone issue.
- tsp42 - 2011-10-21 00:13
fiveisalive Wrote:Thanks! Phew, glad I'm not the only one to see this. Were you resetting just the EPG or PVR database or both? I can reproduce the problem, with resetting the EPG database only.I reset the PVR database. Afterwards the end time in the EPG was set to 1671 something as you also reported. I will look further into it tomorrow. It doesn't happen in windows and I mainly developing the add-on in visual c++ so it takes a little more effort to debug in kdevelop.
- fiveisalive - 2011-10-21 01:59
tsp42 Wrote:It is a limitation of the pvr-branch. See issue 273
Oh well back to bug hunting
Does this mean that the show would have to be imported into the video library in order for resume to work? I'd like to keep my recorded shows "segregated" into the PVR add-on, until such time as I want to import it into the video library. The resume feature should be orthogonal to the video library import feature.
- fiveisalive - 2011-10-21 06:58
tsp42 Wrote:I reset the PVR database. Afterwards the end time in the EPG was set to 1671 something as you also reported. I will look further into it tomorrow. It doesn't happen in windows and I mainly developing the add-on in visual c++ so it takes a little more effort to debug in kdevelop.
By the way, dushmaniac requested I file a detailed bug report with logs, so I I've filed it at github here:
https://github.com/opdenkamp/xbmc/issues/277
And after some trial-and-error. I found a (partial) solution (also posted here: https://github.com/opdenkamp/xbmc/issues/277#issuecomment-2478152 )
I noticed that all the EPG events themselves are stored within the PVR add-on in UTC but the EPG cleanups, i.e. the timestamps about when to refresh the EPG data itself are done in local time, that is, all except one place where UTC was used in place of local time. in CEpgContainer::UpdateEntry, the NextEpgUpdate variable is populated using the UTC (rather than local time), creating a skew, meaning the event window doesn't get populated. The following patch fixed it for me:
https://gist.github.com/1303227
However, I still have some clock skew events like Jimmer has reported, where the events are off by an hour in the timeline grid, but appear Ok when you look at the detailed view.
- fiveisalive - 2011-10-21 08:36
Another (separate EPG) issue (could be PVR-wide and not add-on specific). The timeline view appears to respect channels set as 'hidden' in the mythbackend, but not the "EPG: Now" and "EPG: Next" views, which show guide data for hidden channels.
Update: found the source of the problem, bug report and patch here against dushmaniac's branch:
https://github.com/opdenkamp/xbmc/issues/278
- fiveisalive - 2011-10-21 09:26
New issue (seems to be the day!) Now that my EPG is looking better, starting looking at the timer screen more. I've noticed that for some of my schedules (a much better word than "timers", IMHO) in the mythbackend/frontend that they don't have a channel assigned to them, but they record perfectly fine (because they can record on any channel, or the channel was renamed in the backend). Unfortunately the PVR add-on doesn't display any schedules lacking a channel number.