Change History (14)

I would think that the part before the colon represents the protocol (e.g. http: ftp: etc.), and SHOULD be lowercased. I suggest this is not a bug in QT but a feature. Maybe URL is being used incorrectly somewhere, if this is causing a problem.

I would think that the part before the colon represents the protocol (e.g. http: ftp: etc.),

Indeed. The "scheme".

and SHOULD be lowercased.

Probably MAY.

I suggest this is not a bug in QT but a feature. Maybe URL is being used incorrectly somewhere, if this is causing a problem.

Indeed. That was why I suggested that if the data type is a URL (it is), it should be a properly formed URL, and making a file:filename URL does seem to work. The patch in PR is applied here and seems to be working so far.

I am not familiar with the code here. Should the input string be a filename or should it be a URL? Maybe the caller should be formatting the string as ​file://something. If the caller is actually doing that in some cases, then changing the code to use QUrl::fromLocalFile may cause a problem.

The caller doesn't know that internally the BE is storing that item in a URL data type. The caller is just given a list of items and chooses one. If the BE wants the caller to choose a URL it should give it a list of URLs and not plain names.

If the caller is actually doing that in some cases, then changing the code to use QUrl::fromLocalFile may cause a problem.

So how about the update I just made to the PR then to only make it a ​file:// URL if it's not already a URL with a scheme?

It looks like you have renamed your recording files and now cannot access them from Kodi. Recording files have names similar to 2781_20170412152900.ts . If you have renamed your recording files and updated the database with the new names, that is not supported. If you want to access your recording files with friendly names, you can use mythlink.pl which creates symbolic links (​https://www.mythtv.org/wiki/Mythlink.pl).

So, we'll just ignore and leave this very demonstrable bug in place simply because it's not affecting the official Myth FE (yet)? We'll just leave it as a time bomb waiting to break something in the future instead of taking an opportunity to fix it now, yes?

I've gone to the effort of finding the bug and providing a patch that fixes it. And I've even spent the time to revise the patch to address the only issue you found when you reviewed it. Why wouldn't we apply it now?

Why did you point out something you wanted fixed in the patch only to now say you don't want to apply it after I have spent the time addressing the issue you wanted fixed? If you had no intention of applying the patch, why did you waste my time like that?

On the mailing list people harp on and on about how this project accepts patches. I've supplied a patch and now you are not accepting it. Why not?

The symlink solution does not work because when a (i.e. cppmyth) FE accessing the symlinks deletes a recording it only deletes the symlink, not the actual recording.

I don't understand. What is broken that you are fixing by renaming recording files?

The Kodi PVR addon should properly display the metadata of the recording with the original file name.

By manually fiddling with the recording file names you are leaving the tested and supported scenarios, thus finding little issues all over the place.
My short term suggestion is to just avoid the colon and some other special characters that are known to have issues on some operating systems. Or move the cleaned up recordings over to the video library and thus stay on the suggested and supported path that is known working.

I don't understand. What is broken that you are fixing by renaming recording files?

Does it really matter?

The bottom line here is that there is an identified bug and patch has been supplied to fix it.

And seemingly a strange reluctance to fix a clearly identified bug.

By manually fiddling with the recording file names you are leaving the tested and supported scenarios, thus finding little issues all over the place.

Except that I don't find any, other than this one. Other than this issue, renaming the files and updating the DB accordingly works fine.

My short term suggestion is to just avoid the colon and some other special characters that are known to have issues on some operating systems. Or move the cleaned up recordings over to the video library and thus stay on the suggested and supported path that is known working.

Sure. I could do either of those or any number of other things.

None of that will change the fact that there is a bug lurking, waiting to surface for somebody else some day.

I'm honestly quite puzzled why there is so much resistance to fix a bug when all of the hard work of finding the bug and create a fix for it has been done. I'm puzzled why I am preached at that the MythTV project "accepts patches" and when I take the time to write one up and submit it, there is no desire to land it.

I've not looked at your patch or any of the affected code but I think the danger is fixing this problem for one Kodi user could break things for ALL MythTV users so it's only right there is some caution here.

Because it's the wrong fix. It alters the interface for file transfers that may cause problems for others in the future.

Myth has too many ugly tweaks already. This is one area that is well-defined, so we should preserve that.

Your issue isn't the colon; it's that the file isn't being specified as a local file. Assuming it is a local file may work for you. Many of us keep private patches for our own. But we only commit patches that benefit everyone and don't break things.

Note that the prefix "/" denotes it's a local file and Myth handles it correctly.

I suggest you reopen the issue with Kodi PVR.

The filename returned by the services API ("This:") won't have a prefix because the services don't require it. However Kodi PVR is then using the internal Myth protocol for playback, which does.
They should be adding a prefix "/".

You are the first to notice their bug because you are probably the first Kodi PVR user to use colons in filenames.