[qz3fwd]

I posted a while back about exposing a firewire AVHDD disc player/recorder subunit as a PVR backend.
Well, I have studied the several of the existing PVR source implementations and have coded up myself a PVR backend & client to interface with XBMC, but I have a couple questions which I am not clear on. The existing add-on wiki pages seem to describe a scripted addon, not a compiled c++ add on?

BTW - I have only been looking at the PVR source code for a couple of days and at this point dont really understand the XBMC code base / architecture.

Here are several questions:
1. PVR Setup: I need to attempt to fetch a persisted GUID for the firewire device to use, and if either the PVR has not ever been setup or the persisted GUID no longer is on the 1394 network, I need to programatically present to the user a list of device GUID's currently on the network to choose from. Do I need to overwrite the settings.xml file and somehow force a reload?

2. PVR_STREAM_PROPERTIES: presumably XBMC assumes there is only 1 stream at a time, either live TV or a recorded transport stream, so the stream_properties would apply to whichever is currently in use? What specification does unsigned int iCodecType / iCodecId refer to?

3. Channel Scanning: Can someone describe the use of DialogChannelScan() & CallMenuHook()

4. In Progress Recordings: The GetRecordings method fetches a list of recordings from the backend. How does XBMC keep track of continuously changing values of in-progress recordings such as the iDuration member?

5. Are there instructions for compiling and packaging a PVR add on seperate from the rest of XBMC (for OSX)?
I would like to compile my add on and install using my existing installation and avoid compiling the entire code base of XBMC from scratch if at all possible.

[FernetMenta]

Hi,

1)
You can't interact with the user in the settings dialog. See CallMenuHook
2)
Codec type id id follow ffmpeg. For that reason we have avcodec.h in the source tree in order to compile the addons independently from XBMC.
3)
DialogChannelScan() was used in early stages of vnsi but decayed and afaik not used by any of the addons in the repo. For an example of CallMenuHook see my vnsi4 branch: https://github.com/FernetMenta/xbmc-pvr-...tree/vnsi4. It places a hook into "Client specific settings" with brings up the ANSIAdmin dialog for configuration of the backend.
4)
Addons can call a trigger to update recordings but his won't help when ffmpeg demuxer is used for playing a in-progress recording. Currently duration is not updated after the file was opened.
This is somehow related to timeshift and buffers. We need to present the buffer states to the user by having more than a single progress bar.
5)
The addons repo is self contained. You don't need XBMC for compilation.

[qz3fwd]

Hi,

1)
You can't interact with the user in the settings dialog. See CallMenuHook
2)
Codec type id id follow ffmpeg. For that reason we have avcodec.h in the source tree in order to compile the addons independently from XBMC.
3)
DialogChannelScan() was used in early stages of vnsi but decayed and afaik not used by any of the addons in the repo. For an example of CallMenuHook see my vnsi4 branch: https://github.com/FernetMenta/xbmc-pvr-...tree/vnsi4. It places a hook into "Client specific settings" with brings up the ANSIAdmin dialog for configuration of the backend.
4)
Addons can call a trigger to update recordings but his won't help when ffmpeg demuxer is used for playing a in-progress recording. Currently duration is not updated after the file was opened.
This is somehow related to timeshift and buffers. We need to present the buffer states to the user by having more than a single progress bar.
5)
The addons repo is self contained. You don't need XBMC for compilation.

Thanks for the feedback.

I have finished coding all of the interface functions in my PVR class and written the client.h/cpp files with the specific needs for my add on and everything cleanly compiles. I need to look into and create everything in the resources folder and then figure out how to package everything up for testing within xbmc.

[opdenkamp]

you can create by running "make zip" in the root of the add-on sources repos, which you can load in XBMC

[qz3fwd]

I have a second PVR which I have developed to control a firewire disc subunit such as the Sony MDS-LSA1/CDP-LSA1 (A&M)
or RCA DVR2160/Toshiba Symbio AVHDD's (MPEG2-TS)/Pioneer DV-79AVi. In other words the PVR controls consumer electronics harware.

It uses Apple's FirewireSDK26, so only runs on OSX.

In the OpenRecordedStream member function I configure the hardware device to
output the requested recording on one of the hardware's isoch output plugs through the firewire interface to the mac which will receive the content for presentation to XBMC.

The content could be audio & music, or mpeg2-ts depending on the hardware being controlled.
So, I use an AVCDevice object from the SDK to create a universal receiver stream to receive the content.
Once the stream object is created, I start playback and let the receive callback grab the content.

The question I have is on the firewire side the model is more like push, while on the xbmc side the model seems to be more like a pull model.
So, once I initiate isoch packets flowing, what is the best way to handle the different data models to make sure data is not lost?