- Welcome to Loggytronic Forum.
Recent posts
#61
VOMP for Raspberry Pi / Re: Feature Request: Immediate...
Last post by pbriesch - May 23, 2015, 05:32:23PUSH 
#62
VOMP General / MVP / Re: Further issue with file si...
Last post by MartenR - April 21, 2015, 07:15:15The ftell is already an ftello in the scraper_support branch in git.
Please use for further testing the development branch scraper_support, both on client and server side.
It will soon lead to an release.
The segments corresponds to the files of the recording, their number starts at 1.
That is the reason.
Marten
Please use for further testing the development branch scraper_support, both on client and server side.
It will soon lead to an release.
The segments corresponds to the files of the recording, their number starts at 1.
That is the reason.
Marten
#63
VOMP General / MVP / Further issue with file size >...
Last post by ralph - April 20, 2015, 19:22:41Last week I posted this: http://forum.loggytronic.com/index.php?topic=757.0. Thx a lot for the fast feedback.
Now I tried to understand what went wrong and I found that one problem is the variable type (always 32 bit) while the ftell will only fail on 32-bit systems as the long argument is only 32bit wide there while on 64-bit systems the long argument is 64-bit wide. I had a look for similar issues and found another one in recplayer.c:
The ftell returns a long which is fine on 64-bit systems while the call will return a 32-bit trunated value on 32-bit systems. Since it returns a signed value the result may become even negative!
I suggest that you use ftello instead of ftell. And perhaps switch completely to fseeko even for the working call before ftell.
By the way: Why is the segments[0] array member never used? In C++ counting typically starts at 0.
Now I tried to understand what went wrong and I found that one problem is the variable type (always 32 bit) while the ftell will only fail on 32-bit systems as the long argument is only 32bit wide there while on 64-bit systems the long argument is 64-bit wide. I had a look for similar issues and found another one in recplayer.c:
Code Select
void RecPlayer::scan()
{
.....
segments[i] = new Segment();
segments[i]->start = totalLength;
fseek(file, 0, SEEK_END);
totalLength += ftell(file); // ftell will return a 32-bit (signed) value on 32-bit systems
totalFrames = indexFile->Last();
.....
The ftell returns a long which is fine on 64-bit systems while the call will return a 32-bit trunated value on 32-bit systems. Since it returns a signed value the result may become even negative!
I suggest that you use ftello instead of ftell. And perhaps switch completely to fseeko even for the working call before ftell.
By the way: Why is the segments[0] array member never used? In C++ counting typically starts at 0.
#64
VOMP for Raspberry Pi / Feature Request: Immediate pla...
Last post by pbriesch - April 17, 2015, 16:47:52Hello,
for many years I use VOMP, now on the Raspberry PI.
Especially for not so geeky people and the elderly, VOMP's user interface is easy to master because it is similar to the one of familiar set top boxes.
However, most people expect a TV to play the last channel which has been watched before when it was turned off as soon as the TV is turned on again without any user interaction. When VOMP starts the menu is shown and the user needs to press a button or two to be able to watch a channel: The TV does not behave as an ordinary TV and this could be irritating to some people who just want to watch TV in the first time.
To make VOMP more user-friendly and increase it's user acceptance I would like VOMP to start playing the last watched channel after power on.
Kind regards,
Paul
for many years I use VOMP, now on the Raspberry PI.
Especially for not so geeky people and the elderly, VOMP's user interface is easy to master because it is similar to the one of familiar set top boxes.
However, most people expect a TV to play the last channel which has been watched before when it was turned off as soon as the TV is turned on again without any user interaction. When VOMP starts the menu is shown and the user needs to press a button or two to be able to watch a channel: The TV does not behave as an ordinary TV and this could be irritating to some people who just want to watch TV in the first time.
To make VOMP more user-friendly and increase it's user acceptance I would like VOMP to start playing the last watched channel after power on.
Kind regards,
Paul
#65
VOMP for Raspberry Pi / Re: Playback starts from the b...
Last post by ralph - April 17, 2015, 14:55:27Sorry for posting the issue again. I rebuilt the package and can confirm that the issue is fixed with the change.
Thx
Ralph
Thx
Ralph
#66
VOMP for Raspberry Pi / Re: Playback starts from the b...
Last post by MartenR - April 13, 2015, 06:54:06 #67
VOMP for Raspberry Pi / Playback starts from the begin...
Last post by ralph - April 13, 2015, 00:24:38Hi,
I just updated to a Smart-TV. As this can play videos from VDR filesystem and the recordings in 2GB junks have been inconvenient, especially for HD recordings, I decided to set the maximum file size to 25 GByte. While watching one of the latest recordings the playback suddenly started from the beginning while it was impossible to jump to the end of the video at all. I assume that there is used a 32 bit never for file offset which is not sufficient for the complete recording. The size of the recording is about 6Gbyte. That fits well to the position where the restart happened.
I hope this problem can be reproduced. In the latest VDR versions the file size can be given in the settings. So it is likely that more users change this in future.
Ralph
I just updated to a Smart-TV. As this can play videos from VDR filesystem and the recordings in 2GB junks have been inconvenient, especially for HD recordings, I decided to set the maximum file size to 25 GByte. While watching one of the latest recordings the playback suddenly started from the beginning while it was impossible to jump to the end of the video at all. I assume that there is used a 32 bit never for file offset which is not sufficient for the complete recording. The size of the recording is about 6Gbyte. That fits well to the position where the restart happened.
I hope this problem can be reproduced. In the latest VDR versions the file size can be given in the settings. So it is likely that more users change this in future.
Ralph
#68
VOMP for Raspberry Pi / Re: bug report scraper_support...
Last post by MartenR - April 04, 2015, 14:37:262) is also now changed in git. It goes back to last iframe.
The problem is you never know how long you have to go back, since the resume point is determined on the server side.
That means as resuming point always the last frame, that was streamed to the raspberry pi is taken.
Since we have some buffering, that is always inaccurate.
Marten
The problem is you never know how long you have to go back, since the resume point is determined on the server side.
That means as resuming point always the last frame, that was streamed to the raspberry pi is taken.
Since we have some buffering, that is always inaccurate.
Marten
#69
VOMP for Raspberry Pi / Re: bug report scraper_support...
Last post by MartenR - April 04, 2015, 13:32:221) is now changed in git.
Marten
Marten
#70
VOMP for Raspberry Pi / Re: bug report scraper_support...
Last post by MartenR - March 23, 2015, 07:07:07Ok, then it was the wrong one.
setstartframe should then be changed, with a similar logic.
Marten
setstartframe should then be changed, with a similar logic.
Marten