@bedoiun
Yes, myth backend hang connexion after wake up. That requires a new xbmc feature to stop pvr service on sleep. It is in my todo list.
Also i must update cmyth specs to get guide only for visible channel. It is also in my todo, this update will coming soon (this week).
(2013-01-07, 19:59)cfetzer Wrote: [ -> ] (2013-01-07, 02:14)grouser53 Wrote: [ -> ]Hi,
I'm running Frodo RC3 on raspbmc RC5 and think I'm encountering the seek error listed in #2 here - http://forum.xbmc.org/showthread.php?tid...#pid907205 and this issue - https://github.com/tsp/xbmc/issues/1. Whenever I play mpeg2 SD recordings and use the right arrow key to skip forward, the player exits back to the recording list. This is repeatable on any of my SD recordings, but doesn't happen on HD recordings or LiveTV. I've uploaded a log here - http://www.mediafire.com/download.php?20idnuhryfyroee. Here's the mediainfo on 1 of the affected recordings:
General
ID : 500 (0x1F4)
Complete name : 3005_20121231173000.mpg
Format : MPEG-TS
File size : 1.85 GiB
Duration : 30mn 24s
Overall bit rate mode : Variable
Overall bit rate : 8 696 Kbps
Video
ID : 300 (0x12C)
Menu ID : 1 (0x1)
Format : MPEG Video
Format version : Version 2
Format profile : Main@main
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : M=3, N=15
Codec ID : 2
Duration : 30mn 24s
Bit rate mode : Variable
Bit rate : 7 878 Kbps
Maximum bit rate : 6 000 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate : 29.970 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.761
Stream size : 1.67 GiB (91%)
Audio
ID : 301 (0x12D)
Menu ID : 1 (0x1)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Codec ID : 3
Duration : 30mn 24s
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : -54ms
Stream size : 83.5 MiB (4%)
Any help would be appreciated. I'm using the raspbmc build from 01/05/2013. Please let me know if you need any more information.
I fear that this is not related to the addon. There was an issue with mpeg-ts files, but it has been fixed in xbmc's ffmpeg a while ago and is working fine. Also not all files were affected.
Can you mount your recordings directory directly and start to play the files without using the addon?
@cfetzer
I was able to mount the myth recordings as nfs and play them on raspbmc without the skip issue, i.e. I was able to skip forward and backward with both small and large skip. When I try skipping using the addon, it immediately returns to the recording list. My backend is myth 0.25+fixes and skip works fine on mythfrontend. Have you been able to access the log I linked to? There are some strange messages about skip returning position 0.
(2013-01-07, 20:04)Kr0nZ Wrote: [ -> ][quote='grouser53' pid='1289133' dateline='1357517642']
Hi,
I'm running Frodo RC3 on raspbmc RC5 and think I'm encountering the seek error listed in #2 here - http://forum.xbmc.org/showthread.php?tid...#pid907205 and this issue - https://github.com/tsp/xbmc/issues/1.
Looks like your using an old build, because you linked to TSP's github... Dont use TSP's builds... use cfetzer's or janbar's
http://wiki.xbmc.org/index.php?title=PVR...FromSource
cfetzer / janbar:
Maybe this thread should be started over so the first post can be updated with correct info?
I only used the tsp issue as an example of the issue I'm encountering. The build I'm using is the current build included with RC5 of raspbmc which pulls from the xbmc sources.
Have you seen the seek problem also in previous versions? There were a couple of commits in xbmc recently that claim to have fixed some problems in seeking pvr streams.
Can you try to use tomorrow's nightly build?
(2013-01-08, 21:33)cfetzer Wrote: [ -> ]Have you seen the seek problem also in previous versions? There were a couple of commits in xbmc recently that claim to have fixed some problems in seeking pvr streams.
Can you try to use tomorrow's nightly build?
I loaded the nightly build 20130109 and the issue persists. I realize that you don't think this is addon related, but the xbmc player (omxplayer in raspbmc) seek works correctly when the mythtv recordings directory is mounted via nfs to the pi. I read somewhere (maybe in this forum) that some conversion needs done between time and frame seeking in the addon. Could that be contributory? I've noticed that the skip commercial functionality of mythtv also doesn't work correctly on these recordings. It usually skips too far. These recordings were encoded by a Hauppauge 1600 from an analog cable feed. The times listed in mythtv for the longer recordings also appear incorrect with 1 hour recordings showing around 52 minutes. Perhaps if you or janbar could take a look at the log
http://www.mediafire.com/download.php?20idnuhryfyroee there might be some hints. Thank you for your attention to this and your and janbar's work on the addon.
Hi all again.
I am seeing an issue with the Channel List in live tv for a backend that has multiple tuners.
My mythtv has 2 tuners, each has its own video source.. (one has HD, the other doesn't)
My XBMC settings for Live TV has 'Use backend channels numbers' set to true.
This makes the EPG work fine, (if that setting is false the EPG shows duplicate channels)
But if I go to LiveTV -> TV Channels
then there are duplicate channels shown.
Is this a cmyth issue or a general xbmc issue?
(2013-01-05, 03:04)tdavis Wrote: [ -> ]I've figured out what is wrong, but I have no idea how to correct it.
Myth is reporting in the DB that frame is fixed, for the whole recording. This is not true; using mplayer, I get these messages:
demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
A:47551.5 V:47551.5 A-V: 0.041 ct: 0.070 2556/2529 27% 0% 1.0% 0 0
Warning! FPS changed 23.976 -> 29.970 (-5.994005) [4]
A:47557.6 V:47557.6 A-V: -0.003 ct: 0.119 2739/2710 27% 0% 1.0% 0 0
demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
A:47557.9 V:47557.9 A-V: 0.038 ct: 0.137 2747/2717 27% 0% 1.0% 0 0
demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
A:47557.9 V:47557.9 A-V: 0.041 ct: 0.141 2748/2718 27% 0% 1.0% 0 0
Warning! FPS changed 23.976 -> 29.970 (-5.994005) [4]
A:47558.4 V:47558.4 A-V: 0.009 ct: 0.177 2763/2731 27% 0% 1.0% 0 0
demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
A:47559.4 V:47559.3 A-V: 0.042 ct: 0.229 2787/2755 27% 0% 1.0% 0 0
demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
A:47559.4 V:47559.4 A-V: 0.044 ct: 0.233 2788/2756 27% 0% 1.0% 0 0
Warning! FPS changed 23.976 -> 29.970 (-5.994005) [4]
A:47563.4 V:47563.4 A-V: -0.006 ct: 0.287 2910/2875 27% 0% 1.0% 0 0
demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
A:47564.2 V:47564.2 A-V: 0.042 ct: 0.325 2931/2895 27% 0% 1.0% 0 0
demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
A:47564.3 V:47564.2 A-V: 0.045 ct: 0.329 2932/2896 27% 0% 1.0% 0 0
Warning! FPS changed 23.976 -> 29.970 (-5.994005) [4]
A:47573.5 V:47573.5 A-V: -0.005 ct: 0.384 3210/3168 27% 0% 1.0% 0 0
demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
A:47595.8 V:47595.7 A-V: 0.041 ct: 0.562 3747/3705 27% 0% 1.0% 0 0
demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
A:47595.8 V:47595.7 A-V: 0.049 ct: 0.566 3748/3706 27% 0% 1.0% 0 0
Warning! FPS changed 23.976 -> 29.970 (-5.994005) [4]
A:47596.1 V:47596.1 A-V: 0.025 ct: 0.592 3758/3714 27% 0% 1.0% 0 0
demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
A:47600.7 V:47600.7 A-V: 0.040 ct: 0.658 3871/3826 27% 0% 1.0% 0 0
demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
A:47600.8 V:47600.7 A-V: 0.047 ct: 0.662 3872/3827 27% 0% 1.0% 0 0
Warning! FPS changed 23.976 -> 29.970 (-5.994005) [4]
A:47656.4 V:47656.4 A-V: -0.002 ct: 0.712 5541/5496 28% 0% 1.0% 0 0
Which means.. This is breaks everything, because the time stamps are calculated using a single frame rate for the whole recording, and this recording switches between 2 FPS as it plays (and strangely, it's not where on scene changes, but in the middle of a scene!)
So it keeps switching between 23.976 and 29.970 and then back.. which means by the time it gets to where Myth says a commercial should be, XBMC is claiming it's another 15 seconds of video!
This is recorded using a HDHomerun Prime, on Comcast, with cable card.. time to check and see if this occurring in the OTA recordings (HDHome Dual).
I just checked an OTA recording, and they do not have these frame rate changes; so Comcast & the Prime's are doing wierd.
Well, indeed, this breaks the addon code. I was hoping that tv networks wouldn't do this, but apparently they do.
I can however not reproduce this with dvb in europe (quickly checked a few files).
Could you maybe upload a sample file somewhere so that I can start playing around?
I found this related thread and an algorithm that might work here:
http://forum.xbmc.org/showthread.php?tid...pid1104199
(2013-01-10, 01:54)grouser53 Wrote: [ -> ] (2013-01-08, 21:33)cfetzer Wrote: [ -> ]Have you seen the seek problem also in previous versions? There were a couple of commits in xbmc recently that claim to have fixed some problems in seeking pvr streams.
Can you try to use tomorrow's nightly build?
I loaded the nightly build 20130109 and the issue persists. I realize that you don't think this is addon related, but the xbmc player (omxplayer in raspbmc) seek works correctly when the mythtv recordings directory is mounted via nfs to the pi. I read somewhere (maybe in this forum) that some conversion needs done between time and frame seeking in the addon. Could that be contributory? I've noticed that the skip commercial functionality of mythtv also doesn't work correctly on these recordings. It usually skips too far. These recordings were encoded by a Hauppauge 1600 from an analog cable feed. The times listed in mythtv for the longer recordings also appear incorrect with 1 hour recordings showing around 52 minutes. Perhaps if you or janbar could take a look at the log http://www.mediafire.com/download.php?20idnuhryfyroee there might be some hints. Thank you for your attention to this and your and janbar's work on the addon.
Well the code that reads the recordings is not very large and hasn't been changed recently. That's why I keep thinking it might be the pvr code.
XBMC does time based seeking, MythTV does it frame based. But its only relevant for bookmark positions.
What do you mean with commercial skip functionality doesn't work correctly? XBMC Frodo PVR addons can't do this at all at the moment.
I'll try if I can reproduce it, but it might take a couple of days.
(2013-01-10, 18:23)richardambridge Wrote: [ -> ]Hi all again.
I am seeing an issue with the Channel List in live tv for a backend that has multiple tuners.
My mythtv has 2 tuners, each has its own video source.. (one has HD, the other doesn't)
My XBMC settings for Live TV has 'Use backend channels numbers' set to true.
This makes the EPG work fine, (if that setting is false the EPG shows duplicate channels)
But if I go to LiveTV -> TV Channels
then there are duplicate channels shown.
Is this a cmyth issue or a general xbmc issue?
What version of the addon do you use? The development version in git should combine channels if they share the same channum and callsign:
https://github.com/fetzerch/xbmc-pvr-add...740d43a407
(2013-01-10, 21:50)cfetzer Wrote: [ -> ] (2013-01-05, 03:04)tdavis Wrote: [ -> ]I've figured out what is wrong, but I have no idea how to correct it.
Myth is reporting in the DB that frame is fixed, for the whole recording. This is not true; using mplayer, I get these messages:
demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
A:47551.5 V:47551.5 A-V: 0.041 ct: 0.070 2556/2529 27% 0% 1.0% 0 0
Warning! FPS changed 23.976 -> 29.970 (-5.994005) [4]
A:47557.6 V:47557.6 A-V: -0.003 ct: 0.119 2739/2710 27% 0% 1.0% 0 0
demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
A:47557.9 V:47557.9 A-V: 0.038 ct: 0.137 2747/2717 27% 0% 1.0% 0 0
demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
A:47557.9 V:47557.9 A-V: 0.041 ct: 0.141 2748/2718 27% 0% 1.0% 0 0
Warning! FPS changed 23.976 -> 29.970 (-5.994005) [4]
A:47558.4 V:47558.4 A-V: 0.009 ct: 0.177 2763/2731 27% 0% 1.0% 0 0
demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
A:47559.4 V:47559.3 A-V: 0.042 ct: 0.229 2787/2755 27% 0% 1.0% 0 0
demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
A:47559.4 V:47559.4 A-V: 0.044 ct: 0.233 2788/2756 27% 0% 1.0% 0 0
Warning! FPS changed 23.976 -> 29.970 (-5.994005) [4]
A:47563.4 V:47563.4 A-V: -0.006 ct: 0.287 2910/2875 27% 0% 1.0% 0 0
demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
A:47564.2 V:47564.2 A-V: 0.042 ct: 0.325 2931/2895 27% 0% 1.0% 0 0
demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
A:47564.3 V:47564.2 A-V: 0.045 ct: 0.329 2932/2896 27% 0% 1.0% 0 0
Warning! FPS changed 23.976 -> 29.970 (-5.994005) [4]
A:47573.5 V:47573.5 A-V: -0.005 ct: 0.384 3210/3168 27% 0% 1.0% 0 0
demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
A:47595.8 V:47595.7 A-V: 0.041 ct: 0.562 3747/3705 27% 0% 1.0% 0 0
demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
A:47595.8 V:47595.7 A-V: 0.049 ct: 0.566 3748/3706 27% 0% 1.0% 0 0
Warning! FPS changed 23.976 -> 29.970 (-5.994005) [4]
A:47596.1 V:47596.1 A-V: 0.025 ct: 0.592 3758/3714 27% 0% 1.0% 0 0
demux_mpg: 24000/1001fps progressive NTSC content detected, switching framerate.
A:47600.7 V:47600.7 A-V: 0.040 ct: 0.658 3871/3826 27% 0% 1.0% 0 0
demux_mpg: 30000/1001fps NTSC content detected, switching framerate.
A:47600.8 V:47600.7 A-V: 0.047 ct: 0.662 3872/3827 27% 0% 1.0% 0 0
Warning! FPS changed 23.976 -> 29.970 (-5.994005) [4]
A:47656.4 V:47656.4 A-V: -0.002 ct: 0.712 5541/5496 28% 0% 1.0% 0 0
Which means.. This is breaks everything, because the time stamps are calculated using a single frame rate for the whole recording, and this recording switches between 2 FPS as it plays (and strangely, it's not where on scene changes, but in the middle of a scene!)
So it keeps switching between 23.976 and 29.970 and then back.. which means by the time it gets to where Myth says a commercial should be, XBMC is claiming it's another 15 seconds of video!
This is recorded using a HDHomerun Prime, on Comcast, with cable card.. time to check and see if this occurring in the OTA recordings (HDHome Dual).
I just checked an OTA recording, and they do not have these frame rate changes; so Comcast & the Prime's are doing wierd.
Well, indeed, this breaks the addon code. I was hoping that tv networks wouldn't do this, but apparently they do.
I can however not reproduce this with dvb in europe (quickly checked a few files).
Could you maybe upload a sample file somewhere so that I can start playing around?
I found this related thread and an algorithm that might work here: http://forum.xbmc.org/showthread.php?tid...pid1104199
I saw that thread, and I think we should move this portion of the discussion there.
I'll work on cutting down a file that does it, I might just go view liveTV and grab the resulting file and see if it has this problem; however, they are still HUGE (mpeg2, 30 minutes is 2.2GB from the CableCard..)
(2013-01-10, 22:04)cfetzer Wrote: [ -> ] (2013-01-10, 01:54)grouser53 Wrote: [ -> ] (2013-01-08, 21:33)cfetzer Wrote: [ -> ]Have you seen the seek problem also in previous versions? There were a couple of commits in xbmc recently that claim to have fixed some problems in seeking pvr streams.
Can you try to use tomorrow's nightly build?
I loaded the nightly build 20130109 and the issue persists. I realize that you don't think this is addon related, but the xbmc player (omxplayer in raspbmc) seek works correctly when the mythtv recordings directory is mounted via nfs to the pi. I read somewhere (maybe in this forum) that some conversion needs done between time and frame seeking in the addon. Could that be contributory? I've noticed that the skip commercial functionality of mythtv also doesn't work correctly on these recordings. It usually skips too far. These recordings were encoded by a Hauppauge 1600 from an analog cable feed. The times listed in mythtv for the longer recordings also appear incorrect with 1 hour recordings showing around 52 minutes. Perhaps if you or janbar could take a look at the log http://www.mediafire.com/download.php?20idnuhryfyroee there might be some hints. Thank you for your attention to this and your and janbar's work on the addon.
Well the code that reads the recordings is not very large and hasn't been changed recently. That's why I keep thinking it might be the pvr code.
XBMC does time based seeking, MythTV does it frame based. But its only relevant for bookmark positions.
What do you mean with commercial skip functionality doesn't work correctly? XBMC Frodo PVR addons can't do this at all at the moment.
I'll try if I can reproduce it, but it might take a couple of days.
Sorry I wasn't clear. I was referring to the commercial skip when using the myth frontend that doesn't work correctly, usually skipping too far. Here's the version of XBMC (12.0-RC3 Git:20130108-8c7ce56), Platform: Linux (Debian GNU/Linux 7.0 (wheezy), 3.6.11 armv6l). Built on Jan 9 2013. Here's uname -a from the pi - Linux raspbmc 3.6.11 #1 PREEMPT Sat Dec 29 00:16:57 UTC 2012 armv6l GNU/Linux. Let me know if you need anything else from me. Thanks for looking into this.
(2013-01-10, 22:04)cfetzer Wrote: [ -> ] (2013-01-10, 18:23)richardambridge Wrote: [ -> ]Hi all again.
I am seeing an issue with the Channel List in live tv for a backend that has multiple tuners.
My mythtv has 2 tuners, each has its own video source.. (one has HD, the other doesn't)
My XBMC settings for Live TV has 'Use backend channels numbers' set to true.
This makes the EPG work fine, (if that setting is false the EPG shows duplicate channels)
But if I go to LiveTV -> TV Channels
then there are duplicate channels shown.
Is this a cmyth issue or a general xbmc issue?
What version of the addon do you use? The development version in git should combine channels if they share the same channum and callsign:
https://github.com/fetzerch/xbmc-pvr-add...740d43a407
Using latest version. Here is a log file
http://paste.ubuntu.com/1519299/
Log file generated as, start xbmc, Live Tv, TV Channels, exit TV Channels is showing multiple BBC ONE, BBC Two, etc.
(2013-01-11, 10:47)richardambridge Wrote: [ -> ] (2013-01-10, 22:04)cfetzer Wrote: [ -> ] (2013-01-10, 18:23)richardambridge Wrote: [ -> ]Hi all again.
I am seeing an issue with the Channel List in live tv for a backend that has multiple tuners.
My mythtv has 2 tuners, each has its own video source.. (one has HD, the other doesn't)
My XBMC settings for Live TV has 'Use backend channels numbers' set to true.
This makes the EPG work fine, (if that setting is false the EPG shows duplicate channels)
But if I go to LiveTV -> TV Channels
then there are duplicate channels shown.
Is this a cmyth issue or a general xbmc issue?
What version of the addon do you use? The development version in git should combine channels if they share the same channum and callsign:
https://github.com/fetzerch/xbmc-pvr-add...740d43a407
Using latest version. Here is a log file http://paste.ubuntu.com/1519299/
Log file generated as, start xbmc, Live Tv, TV Channels, exit TV Channels is showing multiple BBC ONE, BBC Two, etc.
I'd need to see the content of your mythtv channel table (for 2 channels that should be combined as one).
Did you verify that callsign and channum are the same for those channels?
(2013-01-04, 14:38)Nachteule Wrote: [ -> ]@janbar
(2013-01-03, 19:34)janbar Wrote: [ -> ]@Nachteule
I have analyzed your previous log about stop show (few post ago). Well , after event "done_recording" your backend continue to send "i am recording the old prog". This is crazy. I can build a workaround for that without force chain update when we haven't need. Then you could try it.
yes, of course. It would be great I'm sure your workaround will be better than mine, because you know more about internals of myth frontend/backend communication.
Yesterday i modified again my hack and now it works without any retries needed. In summary, after receiving a "recording done" i wait for 250ms before requesting proginfo. Since this modification no more retries were needed. It seems backend send's a little bit too early "done recording" and hasn't really done this job completely.
Hi nachteule,
I made a PR to resolve your case. It is PR#79.
The new code is added into the done_recording function. Here it has no impact on the normal flow because this function was designed to resolve the program break issue for a last chance. I based the patch using your solution: retrying call 3 times. I hope it resolve your issue. Thanks.
br
(2013-01-10, 01:54)grouser53 Wrote: [ -> ] (2013-01-08, 21:33)cfetzer Wrote: [ -> ]Have you seen the seek problem also in previous versions? There were a couple of commits in xbmc recently that claim to have fixed some problems in seeking pvr streams.
Can you try to use tomorrow's nightly build?
I loaded the nightly build 20130109 and the issue persists. I realize that you don't think this is addon related, but the xbmc player (omxplayer in raspbmc) seek works correctly when the mythtv recordings directory is mounted via nfs to the pi. I read somewhere (maybe in this forum) that some conversion needs done between time and frame seeking in the addon. Could that be contributory? I've noticed that the skip commercial functionality of mythtv also doesn't work correctly on these recordings. It usually skips too far. These recordings were encoded by a Hauppauge 1600 from an analog cable feed. The times listed in mythtv for the longer recordings also appear incorrect with 1 hour recordings showing around 52 minutes. Perhaps if you or janbar could take a look at the log http://www.mediafire.com/download.php?20idnuhryfyroee there might be some hints. Thank you for your attention to this and your and janbar's work on the addon.
I've tested now both raspbmc and openelec. Both play and skip fine hd and sd recordings (if mpeg2 codec is enabled). Any chance that you upload a sample file? (for example on dropbox)