MVP mp3 file size problem

[ubu]

I'm trying to get my plugin to play audio streams on a MediaMVP (any stream, not just Shoutcast). I'm transcoding the stream to an mp3 file and then using the GB-PVR audio player to play the file while it's being recorded. This works fine on a standard GB-PVR instance but, when I try to use an MVP for playback, it plays for a few seconds and then stops.

From the log, it looks as if the GB-PVR MVP dongle code is retrieving the file size when it starts to play the file (and the file has only been recorded to for a few seconds). It then plays the file until it has read that many bytes and then stops playing. The regular audio playback code doesn't seem to need to know the size of the file. It just plays it until there's no more file to play.

Is there a work-around for this? I can't see any way to tell the MVP code to ignore the file-size or even a way to access (or set) the file size variable before or during playback.

[HtV]

Of course there is a way, however I don't know it:p . But when you listen to internet-radio it does what you want. It creates a growing mp3 file and that is being played back by the mvp. Maybe this helps.

[ubu]

Of course there is a way, however I don't know it:p . But when you listen to internet-radio it does what you want. It creates a growing mp3 file and that is being played back by the mvp. Maybe this helps.

After a bit more testing and getting the mp3 to play for a few more seconds, it turns out that the MVP playback is changing its file size number as the file grows. But then it catches up, asks for more bytes than are available and gives up.

Code:

1/18/2007 1:51:08 AM.734    VERBOSE    [16]    Request 2000 bytes (file size:125387   file location: 120000)
1/18/2007 1:51:08 AM.765    VERBOSE    [15]    MVP data read: 1   (9)
1/18/2007 1:51:08 AM.765    VERBOSE    [15]    MVP request processed
1/18/2007 1:51:08 AM.859    VERBOSE    [16]    Request 2000 bytes (file size:125387   file location: 122000)
1/18/2007 1:51:08 AM.890    VERBOSE    [15]    MVP data read: 1   (9)
1/18/2007 1:51:08 AM.890    VERBOSE    [15]    MVP request processed
1/18/2007 1:51:08 AM.984    VERBOSE    [16]    Request 2000 bytes (file size:125387   file location: 124000)
1/18/2007 1:51:08 AM.984    VERBOSE    [16]    Not all bytes read. Got:1387  Filesize now:125387
1/18/2007 1:51:08 AM.984    VERBOSE    [16]    End of stream

So it looks like VLC isn't transcoding the stream fast enough for the MVP (playback on the PC works fine). Probably Net Radio doesn't suffer from the same problem because the Shoutcast streams are already in mp3 format so don't need transcoding. I'm just guessing.

I'm running a 2.2ghz P4, which I imagine is an average system for most MVP users, so just throwing more horse power at the problem doesn't seem like a sensible option. I've heard that VLC's mp3 encoding isn't very fast. Maybe I should try one of the "fast" versions of LAME instead.

In any case, thanks for the "tea and sympathy.

[HtV]

I find it hard to believe that vlc can't keep up on your system. I can encode mp3's on my system (slower than yours) at ~10x. with lame. Depends on the settings.

Edit: but I didn't try with vlc:o

[ubu]

I find it hard to believe that vlc can't keep up on your system. I can encode mp3's on my system (slower than yours) at ~10x. with lame. Depends on the settings.

Edit: but I didn't try with vlc:o

Well, once it gets started, it can keep up fine. I noticed that, if I started the recording and then started playing the mp3 from Music Library (while the mp3 was still growing), it played OK on the MVP. Turns out the time it took me to navigate the GB-PVR menus to get to Music Library was making the difference. I upped my delay time between starting the VLC transcoding process and starting the audio player and now it works absolutely fine. Problem solved. The delay time isn't ideal for rapid channel surfing but, presumably, MVP users are used to fairly sluggish channel changes.

Now, if I could only figure out how to detect when the user has stopped the audio player, I'd be a really happy camper. (There doesn't seem to be an audio equivalent of GetActiveVideoPlayer().isCurrentlyShowingVideo).

[sub]

It doesnt normally cope with music files that are still growing. There is some special case logic that is applied when the app nows its listening to a net radio stream.

I could probably add some API for you if this is needed?

[ubu]

It doesnt normally cope with music files that are still growing. There is some special case logic that is applied when the app nows its listening to a net radio stream.

Well, it seems to be doing a pretty good job of it all the same. Audio playback on the MVP while VLC is writing the mp3 is working quite well for me provided I allow a fairly hefty delay between starting the transcoding process and starting playback. I read in a post by you a while back that having "gbnetradio" in the filename would trigger some special logic for this situation. I'm doing that, just to be on the safe side, but it seems to work OK without it. (By the same token, I'm also crossing my fingers and avoiding walking under ladders. )

I could probably add some API for you if this is needed?

That would be excellent, if you have time. My two biggest needs on this front are:

a) Some way to know when the video player has stopped playing on the MVP. I curently check GetActiveVideoPlayer() and, if it returns null, I know that the user stopped the player or that a bad thing happened to it, so I kill my recording process. This works fine using a standard GB-PVR instance on the PC but doesn't seem to work at all when using the MVP dongle.

b) A way to know if the audio player has died. Similar to a) except that I do know if the user terminates the player because I'm processing the stop keystroke myself. But I still don't know if the player simply failed for some reason. It doesn't throw an exception that I can catch because no "hard" error occurred. This typically happens when the delay time before playing is not big enough. The player sees no more data in the file and says "OK - I'm done". But since my code has no way to know that the player is no longer playing the file, it lets the transcoding process continue merrily recording to the mp3 file ad infinitum. I've considered using GetAudioPlaylist() to see if the list is empty but I'm note sure if that's a totally reliable way to go about it.

If PluginHelper had a couple of methods such as bool IsAudioFilePlaying() and bool IsVideoFilePlaying(), both of which would return the correct result whether the playback was via the standard interface or via the MVP dongle code, I'd be in fat city.

I'd really appreciate some help on these two issues. Thanks in advance.

[ubu]

I now have code which catches all the situations I described in the previous post except one:

I'm using a call to PluginHelper's GetAudioPlaylist to check if an audio file is currently being played. (If the playbackPosition returned is zero, I assume the file is not being played, so kill the process that's recording to the file.) When playing the file using standard GB-PVR (non-MVP) this returns correct values for the trackDuration and playbackPosition parameters. However, when the MVP is doing the playback, GetAudioPlaylist always returns zero in all its parameters, whether the file is being played or not.

This is wierd because a) the MVP responds to other audio-related methods (eg. PausePlaylist) and b) I see other plugins using GetAudioPlaylist where they clearly expect it to work in the MVP case (MVP Music Box, for instance). Any ideas?

I haven't got an answer from sub yet on whether he might expose explicit methods for checking stuff like this. I know he's been out of town so may not have seen my previous post.

[sub]

I'm using a call to PluginHelper's GetAudioPlaylist to check if an audio file is currently being played. (If the playbackPosition returned is zero, I assume the file is not being played, so kill the process that's recording to the file.) When playing the file using standard GB-PVR (non-MVP) this returns correct values for the trackDuration and playbackPosition parameters. However, when the MVP is doing the playback, GetAudioPlaylist always returns zero in all its parameters, whether the file is being played or not.

Unfortunately this is normal. GB-PVR doesnt know the playback position or duration of audio files playing on the MVP, so you just need to keep this in mind when designing any screens.

I haven't got an answer from sub yet on whether he might expose explicit methods for checking stuff like this. I know he's been out of town so may not have seen my previous post.

Sorry, I have got this thread on my list of things to revisit soon, but havnt managed to get to it yet.

[ubu]

Unfortunately this is normal. GB-PVR doesnt know the playback position or duration of audio files playing on the MVP, so you just need to keep this in mind when designing any screens.

Well actually, that's not a problem since I don't much care about the duration or playback position. I just want to know if the bugger is playing at all! Is there any way that GB-PVR can know if the MVP is currently playing an audio file or even if the playlist is empty?

In the log, I see messages such as "End of stream", "MVP Streaming Server received STOP message" and "Song ended. Checking if there are more songs to play" but I don't know who's writing them to the log. I guess I was hoping they meant that GB-PVR did know when these events had happened.

If not, since the PluginHelper has the API available to move about in the playlist (NextPlaylistTrack, PrevPlaylistTrack, etc.) and to detect if the playlist is paused, I though there might be a way to know if it's empty (assuming that the MVP encountering the end of the only item in the list would equate to "empty").

Sorry, I have got this thread on my list of things to revisit soon, but havnt managed to get to it yet.

That's cool. I've pretty much come up with workarounds for everything except this MVP audio playback detection thing, so you can more or less ignore what I said in the earlier posts. However, if, at some point, you could provide an IsAudioFilePlaying() method that worked for both MVP and non-MVP cases, I'd be a very happy camper.