URL for Active Recordings vs. URL for Completed Recordings
#1
I've noticed that when I attempt to play an active recording, even when ServerWMC is set to NOT remux active recordings, XBMC is told to use a "pvr" url to get the file, such as this:

pvr://recordings/* Recording now/CBS Evening News With Scott Pelley, TV (KCBSDT/2.1), 20140422_012801.pvr

However, when I want to watch a completed recording, ServerWMC is told to use an smb url, like this:

smb://username:[email protected]://Recorded TV/CBS Evening News With Scott Pelley...wtv

I have two questions:

1. Why does ServerWMC use a PVR URL for an active recording, even when no remuxing is involved?
2. Is there a way to get ServerWMC to use a PVR URL for completed recordings without remuxingHuh
Reply
#2
A "PVR URL" is an XBMC concept that is used internally and pretty much just boils down to a request to the PVR addon containing a channel number/call sign. Our addon then sends that request to ServerWMC backend who then provides a URL which is ALWAYS in smb protocol. The XBMC log says it is opening "pvr:://whatever" but really we have always sent it back an smb:// path to a file (TS file for remux of liveTV or recording, or the WTV file for completed recording). In other words, ServerWMC is not using sending or understanding PVR URLs at all...

You can turn on LogReplyMessages option in ServerWMC then check its logfile, you will see the replies to OpenLiveStream and OpenActiveRecording etc calls all contain smb:// paths.

XBMC client log file seems to contain the URL requested rather than the URL actually provided by the backend (or possibly goes on to mention the smb path, after it mentions the pvr:// path, if your log level is verbose enough)
pvr.wmc TV addon and ServerWMC Backend Development Team
http://bit.ly/ServerWMC
Reply
#3
Scarecrow,

Thanks for responding, but I think you misunderstood my question.

I understand that the "pvr type" URL is just a referral method between XBMC's Live TV Module and ServeWMC.

What I'm trying to find out is why you aren't using it for completed recordings??

I've been chasing down a bug for a few days now, and I'm pretty sure that it's related to the way that ServerWMC handles completed recordings.

When an XBMC client requests a recording list, ServerWMC sends a list that includes the title of each recording. For active recordings, ServerWMC includes a PVR referral type link even if remuxing of active recordings is turned off. For completed recordings, ServerWMC sends a direct SMB link instead of the PVR type link.

While I totally understand why you've done this (to ease server load) and while it appears to work most of the time, I don't think that XBMC was designed to utilize direct SMB links in the Live TV Module for recordings. I suspect that it was always intended to use PVR links which would prompt a referral link from the third party PVR app. In my case, at least, these SMB links are causing a bug which cause newly recorded programs not to play until I do a library update.

So, what I'm trying to find out is whether there is way to switch ServerWMC so that it provides PVR links to completed recordings so that it will refer the client to the SMB link only AFTER I hit play, instead if handing out direct SMB links in the recording list??

Alternatively, I'm hoping that an earlier version of ServerWMC did it that way and I can just use that instead.
Reply
#4
Hey advocate,

Yes Ive been following all your posts although I havent replied much as Ive been unable to do any local testing or debugging, since Ive been moving house and dont have my dev PC setup with a tv signal currently...

I didnt misunderstand your question, what I was trying to say is we dont "use" pvr type URLs anywhere - they are an internal XBMC concept only. The XBMC logifle may talk about them, but the calls to the PVR addons are using an object model where the Recording (or EPG or Timer or Channel) object are provided. But I sometimes get hung up on technical correctness, when I shouldnt Smile

Rather than thinking your question doesnt make sense because we dont deal with PVR URLs, I guess the intention of your question is more like saying "can we have an option to deal with completed recordings in the same way active recordings are". And i think this would be possible.

The response to GetRecordings() call from XBMC to the backend, provides an EMPTY path for active recordings and a filled out path for completed recordings. When dealing with an EMPTY path, it would appear XBMC probably logs stuff toi it's logfile adbout pvr:// paths, however what it is really doing is making a PVR AddOn call (called OpenRecordedStream) and passes in the recording object as an argument. pvr.wmc addon, pulls the RecordingID from the Recording object passed in, and sends that to ServerWMC backend (call called OpenRecordingStream) and the backend then provides back a smb path to play (remuxed TS file for in progress recording or the completed WTV file if the recording is not in progress).

The backend is already setup to handle this (receiving a request for an OpenRecordingStream when the recording has actually already completed now) and in this case it provides the WTV path in an smb URL. I imagine this would happen on any client that hasnt refreshed the recording list yet, once a recording is completed, so it still has the empty path for the recording and thus still calls OpenRecordedStream/OpenRecordingStream, but the backend knows the recording is now finished so doesnt do any remuxing and just hands back the WTV file.

So yeah, I imagine it should actually be pretty trivial to provide empty paths on all recordings, and thus OpenRecordingStream will get called for all of them, and the backend already handles that situation. Presumably that sequence of events also somehow may correct the issue you've found where the SMB files dont seem to work OK after.

I think there could be problems though, with recordings that are just random orphaned FILES (eg copied from old setups, or whatever, that werent recorded on this WMC). Potentially then we wont be able to find them by RecordingID since they arent really recordings... therefore we might not be able to play those. As opposed to the current setup where they are able to be played because the file URL is passed back to XBMC in the recordings listing. I need some time to play around with it


At the end of the day, the bug that youve found seems very weird though. It doesnt seem to makes sense that XBMC cant play a file over SMB until some other action (library refresh?) has been performed. You would assume we would have heard about it already from users, if it was widespread. Did you end up confirming it is only affecting linux clients or is it also affecting windows clients?
pvr.wmc TV addon and ServerWMC Backend Development Team
http://bit.ly/ServerWMC
Reply
#5
To your final point, I was wondering the same thing as well.

I've now tested five separate OpenELEC boxes running XBMC on two different ServerWMC servers and they all do the same thing. I've made countless configuration changes as well.

The only conclusions that I could come up with are that (1) I'm crazy, (2) most of your users are using Windows XBMC boxes (which probably don't have the issue), (3) most of your users are using Gotham (which may not have the issue), or (4) most of your users are turning their boxes off when they've not using them (and thus they rarely see "new recordings").

A library update isn't the only thing that fixes the problem. If I watch an older show first, or pull a directory listing, that seems to resolve the problem as well. As a result, the problem appears to be intermittent. Some users may have even experienced the problem, but because it went away when the restarted or tried another file, thought nothing of it.

Honestly, I don't know. But, I've spent about 20 hours on this so far, and this is the very best that I can come up with!! Sad

If I understand what you've said, you don't supply any path at all for active recordings, and so it appears that the "PVR" link I see in the XBMC logs and in the ServerWMC logs are generated internally by XBMC when you leave the field blank. That also suggests that XBMC devs did intend you to provide an SMB link (in a completed path) and that kills my theory about the "bug" in ServerWMC. Obviously, if they gave you a field to include a SMB link, they intended that you might use a SMB Link, right?

Honestly, I have zero idea what the cause of this issue is. Sometimes, new recordings won't play.

I believe that I can induce the same issue by changing a file name on the Recorded TV Folder and waiting for the client to pull the new list. Every single time that I do that, the file won't play on any of my five machines, and the XBMC log shows the very same errors. The log will show that XBMC tried to play the correct SMB url, but it failed. The file will start playing again if I update the library, play another file, or reboot my system...

On your question about Windows clients, I haven't had a chance to fully test a Windows client. However, I did find that if I change a filename on a Watched Folder that is hosted by a Linux-based NAS (a ReadyNAS), the Windows client running XBMC Frodo had the same experience, i.e. once it pulled the new file list, it could not play the file until I did a library update...
Reply
#6
One more thing that I noticed from my testing. I noticed that when the problem occurs, the debug log in XBMC gives no information about why the file failed to open.

In order to learn more about XBMC's log files, I checked to see what would happen if I manually deleted a playable file and then attempted to play it. In that case, XBMC gave more detail in the debug logs indicating that the file was not found, but only the FIRST time that I tried to play it. On subsequent attempts, the log gave less detail, and the log looked identical to what I see in my debug logs when the problem occurs and I cannot play a newly completed recording.

This led me to conclude that either XBMC or Linux has some mechanism of keeping track of dead SMB files so that repeated calls to a dead SMB will not go out onto the network until something else is done first. Perhaps what's happening here is that when you add a new SMB file to a completed recording, XBMC is trying to do something with it but cannot, and so it marks it as "dead" and won't honor a second request to access that file until something else is done as well.

Unfortunately, these concepts are well beyond my understanding of Linux and XBMC, so I'm really just grasping at straws here.
Reply
#7
Yeah these things can really do your head in cant they!

If anything it sounds like the way that XBMC plays a recording where the path has been provided, doesnt do whatever handshake/authentication is required, that most other actions (library refresh playing some other older file, whatever) do... Although you are saying that simply playing another existing recording, that was already completed, is enough to do it... so I guess that rules that out, since obviously XBMC would be using the same code to play a completed recording, regardless of whether it is newly completed or already completed!

linux to windows definitely has some funny interactions sometimes. I also have a linux based NAS and have had my fair share of odd file based issues, whether it be permissions/ownership, items showing up despite having been deleted etc

Anyhow I had a further look at the GetRecordings code and we dont do any directory walking, so it seems that all recordings whether they be done by WMC or just files placed in the recording directory, are all known to WMC and thus have a RecordingID etc. In other words my previous comment about a possible issue with imported/orphaned recordings is probably not a concern. So I think on that basis we should be able to provide an option to provide empty paths on all recordings to XBMC, thus causing it to make backend requests for each recording and hopefully kicking your strange issue into submission so that you dont have issues playing newly completed recordings.

Also, I just wanted to nit pick on one particular thing you said...

(2014-04-22, 05:23)advocate99 Wrote: If I understand what you've said, you don't supply any path at all for active recordings, and so it appears that the "PVR" link I see in the XBMC logs and in the ServerWMC logs are generated internally by XBMC when you leave the field blank. That also suggests that XBMC devs did intend you to provide an SMB link (in a completed path) and that kills my theory about the "bug" in ServerWMC. Obviously, if they gave you a field to include a SMB link, they intended that you might use a SMB Link, right?

You said XBMC and ServerWMC logs. Im not aware there are any "PVR links" in ServerWMC logs, they would only be on the XBMC side. Can you clarify/confirm what you meant?
pvr.wmc TV addon and ServerWMC Backend Development Team
http://bit.ly/ServerWMC
Reply
#8
I've seen references to the "PVR" URL in ServerWMC logs when I have attempted to play active recordings. I recall something to the effect of, I received the PVR url, looked up the corresponding SMB file, and sent it back XBMC. If you don't know what I mean, tell me and I'll generate one for you.

Keep in mind that you are already sending blank fields for Recorded TV Files when a user checks the option to Remux all WTV Files. So, all you really need to do is create an option that does that, but doesn't actually Remux the completed recordings.

When you have a chance, please try changing the filename on a recording in your Recorded TV Folder, wait 6 minutes, and attempt to play the file from a remote client. I've tried this repeatedly and without fail, after the Recording List updates, the file will NOT play, but the XBMC log shows that the correct file is being called via SMB.
Reply
#9
Im not at a working ServerWMC setup at the moment, so if its no trouble and you can show me what you mean in the logs, feel free to post an excerpt that shows the pvr URLs in ServerWMC logs

Also, if you PM me your email address I can send you a debug build (untested, as im at work) that will provide empty paths on all recordings in the list

And yeah when I have a devel environment setup at hte new house, I will play around with the rename 6minute thing

Also, regarding XBMC log files. Do you have the loglevel configured to be more verbose? Not thorugh the GUI, you do it in AdvancedSettings.xml That could give you more error codes when the file cant be opened etc, if you arent already doing it
pvr.wmc TV addon and ServerWMC Backend Development Team
http://bit.ly/ServerWMC
Reply
#10
Okay, I'll recreate what I did before. In looking over my existing logs, it is possible that my memory is faulty and that I interpreted an "OpenRecordingStream" entry as corresponding to XBMC's sending of a pvr: url. Since you're a dev, I'm sure you're right on this point.

Bear in mind also that I make a lot of changes to the default XBMC settings, and I'm keeping in mind that one of my myriad changes may be what is causing this phenomenon...

One more thing: I said that changing the filename causes the problem without fail. This isn't completely accurate because there have been one or two times where the problem did not occur in this case. But it occurs most of the time - 90-95%..
Reply
#11
One more, one more thing: It turns out that you don't need to wait five minutes for the Recorded Listings to update. You can just delete another entry that that'll force an update to the list of Recorded programs.
Reply
#12
Yeah deleting an entry will force a recordings update from the backend (and as of the latest build, any other client will be told to do a refresh, the next time it "checks in" with the server, if that occurs before XBMC does it's default recordings refresh)
pvr.wmc TV addon and ServerWMC Backend Development Team
http://bit.ly/ServerWMC
Reply
#13
Okay, I tested the replacement file you sent me.

The problem I reported when changing a filename is completely gone.

If I change a filename, the show plays correctly and immediately both before and after a Recording List update.

I'll have to let the unit sit overnight to see if it solves the bigger problem, i.e. new shows. But, given that it solves the "change filename" problem, I'm pretty sure that it will work...
Reply
#14
Results from the overnight testing seem to indicate that what you sent to me resolves the concern that I was having! Smile
Reply
#15
So we have ruled out that advocate is crazy? Smile

Scarecrow are you planning on pushing up this change (enabled as an option)?
Windows Media Center PVR addon (pvr.wmc) and server backend (ServerWMC)
http://bit.ly/serverwmc
Reply

Logout Mark Read Team Forum Stats Members Help
URL for Active Recordings vs. URL for Completed Recordings0