I would like scrape information for recordings from onlinetvrecorder (otr) in Kodi. Unfortunately the scrapers available can't handle the file format which is like
Django_Unchained_15.07.03_22-45_sf2_165_TVOON_DE.mpg.mp4.avi
Renaming is not an option, since the filename is a key for otr. I know there is a scraper called xbmc-otr, but it never left beta status and seems to be outdated.
Any suggestions, on how to correctly display those files in Kodi?
Has anybody written or started a scraper for otr?
After some research I found a solution to the problem. Put the following in %appdata%\Kodi\userdata\advancedsettings.xml (advancedsettings.xml does not exist in advance, you have to create it)
<advancedsettings>
<video>
<cleanstrings action="prepend">
<regexp>_\d\d\.[0-1]\d\.[0-3]\d_[0-2]\d-[0-5]\d_</regexp>
</cleanstrings>
</video>
</advancedsettings>
The regexp <regexp>_\d\d\.[0-1]\d\.[0-3]\d_[0-2]\d-[0-5]\d_</regexp> matches the timestamp in the otr filename, so that everything right of the match (at the end of the file name) is removed. See the official Kodi documentation for further reference. The remaining file name can be handled by the scrapers shipped with Kodi.
Despite of the relatively coarse regexp I added, all my otr movies were recognized correctly.
The solution is tested with Kodi 15.2 (Isengard), but should work with all versions that support the cleanstrings option.
EDIT:
A similar soltuion works for TV Shows. The only requirement is that the file name contains season and episode information like S01E02 for example.
<tvshowmatching action="prepend">
<regexp>_[Ss]([0-9]+)[Ee]([0-9]+)([^\\/_]*)</regexp>
</tvshowmatching>
Related
Years ago, I wrote a small app in itext2 to gather reports on a weekly basis and concatenate them into one PDF. The app used com.lowagie.text.pdf.PdfCopy to copy and merge the PDFs. And it worked fine. Performed exactly as expected.
A few weeks ago I looked into migrating the application to itex7. To that end, I used the copyPagesTo method of com.itextpdf.kernel.pdf.PdfDocument. When run on the same file set, this produces warnings like:
WARN PdfNameTree - Name "section.1" already exists in the name tree; old value will be replaced by the new one.
When I click on the link to "section.1" in the first document of the merged PDF, I am taken to "section.1" of the last document. Not what I expected and not what happens when using the itext2 app. In the PDF's produced by itext2, if I click on the link to "section.1" of the first document in the combined PDF, I am taken to section 1 of the first document.
There is a hint in Javadocs for copyPagesTo saying
If outlines destination names are the same in different documents, all
such outlines will lead to a single location in the resultant
document. In this case iText will log a warning. This can be avoided
by renaming destinations names in the source document.
There is however, no explanation of how this should be done. I find it odd that this should be necessary in itext7, although it wasn't in itext2.
Is there a simple way to get around his problem?
I've also tried the Sejda desktop app and it produces correct results, but I would prefer to automate the process through a batch script.
My guess is iText 2 didn't even know it might be a problem.
If iText can't deduplicate destination names, the procedure is roughly:
Follow /Catalog -> /Names -> /Dests in each document to find the destination name tree.
Deduplicate the names, by adding suffixes. Remember that a name with a suffix added might be equal to an existing name in the same or another document. Be careful!
Now you can rewrite the destination name trees. Since you have only used suffixes, you can do this in place - the lexicographic ordering of the names is unaltered so the search tree structure is not broken.
Now, rewrite destination links in each PDF for the new names. For example any dictionary entry with key /Dest, or any /D in a /GoTo action.
Now, after all this preprocessing, the files will merge without name clashes.
(I know all this because I've just implemented it for my own PDF software. It's slightly hairy stuff, but not intractable.)
If you like, I can provide a devel version of cpdf with this functionality, if you would like to test it.
I'm sorry if this doesn't have enough information. I don't typically ask for help online like this.
I'm using DITA Open Toolkit 3.4 on Windows. I generated a plugin called "vcr2" using Jarno's (very excellent and helpful) PDF Plugin Generator and then made a handful of customizations. The plugin uses the pdf2 plugin as a base. When I try to use the vcr2 plugin, my images are not working. I've tracked the problem down to malformed image filenames in the image's href attribute.
For example:
In my source file (a DITA Task), the markup for one of my images looks like this:
<image href="MyRemindersChooseReminder.png"/>
If I run a transform with the pdf2 plugin, the images work fine. In the merged stage1.xml file in the Temp folder, the XML for that same image looks like this:
<image class="- topic/image " href="df2d132af27436c59c5c8c4282e112d62bec8201.png" placement="inline" xtrc="image:1;10:66" xtrf="file:/V:/Vasont/Extract/t12340879-minimal/t12340879.xml"/>
It is processed into a file Topic.fo, and looks like this:
<fo:external-graphic
src="url('file:/V:/Vasont/Extract/t12340879-minimal/MyRemindersChooseReminder.png')"/>
Everything works fine and the image looks fine.
If I run the same file through my 'vcr2' plugin, which just calls the same pdf2 plugin with some overrides, all the images get broken:
stage1.xml
<image class="- topic/image " href="df2d132af27436c59c5c8c4282e112d62bec8201.png" placement="inline" xtrc="image:1;10:66" xtrf="file:/V:/Vasont/Extract/t12340879-minimal/t12340879.xml"/>
Topic.fo
<fo:external-graphic
src="url('file:/V:/Vasont/Extract/t12340879-minimal/df2d132af27436c59c5c8c4282e112d62bec8201.png')"
/>
As I track this down further, it appears that somewhere in the map-reader Ant task, this filename gets changed to that cryptic string of pseudo-hexadecimal. I think later on it's supposed to be changed back or resolved to a complete URI or something.
So, the two-part question is: Why does Open Toolkit change my filenames, and what's supposed to change them back?
DITA-OT's preprocess uses hashes for temporary filenames because it allows the code to not deal with directory structures. This enables preprocess to work in so-called "map-first" mode, where it first processes all DITA map resources and only then starts to process DITA topic and image resources.
The preprocess has a step called clean-preprocess that can rewrite the temporary file names to match source resource files names. However, this rewrite operation is disabled for PDF output because the original file names are not used for anything in that output type.
I'm seeing some very strange behavior with FileMaker 14. I'm using LayoutObjectNames for some required functionality. On the development system it's working fine. It returns the list of named objects on the layout.
I close the file, zip it up and send it to the client, and that required functionality isn't working. He sends the file back and I open it and get a data viewer up. The function returns nothing. I go into layout mode and confirm that there are named objects on the layout.
The first time this happened and I tried recovering the file. In the recovered file it worked, so I assumed some corruption had happened on his end. I told him to trash the file I had given him and work with a new version I supplied. The problem came up again.
This morning he sent me the oldest version that the problem manifested in. I confirmed the problem, tried recovering it again, but this time it didn't fix the problem.
I'm at a loss. It works in the version I send him, doesn't on his system. We're both using FileMaker 14, although I'm using Advanced. My next step will be to work from a served file instead of a local one, but I have never seen this type of behavior in FileMaker. Has anyone seen anything similar? Any ideas on a fix? I'm almost ready to just scrap the file and build it again from scratch since we're not too far into the project.
Thanks, Chuck
There is a known issue with the Get (FileName) function when the file name contains dots (other that the one before the extension). I will amend my answer later with more details and a possible solution (I have to look it up).
Here's a quote from 2008:
This is a known issue. It affects not only the ValueListItems()
function, but any function that requires the file name. The solution
is to include the file extension explicitly in the file name. This
works even if you use Get (FileName) to return the file name
dynamically:
ValueListItems ( Get ( FileName ) & ".fp7" ; "MyValueList" )
Of course, this is not required if you take care not to use period
when naming your files.
http://fmforums.com/forums/topic/60368-fm-bug-with-valuelistitems-function/?do=findComment&comment=285448
Apparently the issue is still with us - I wonder if the solution is still the same (I cannot test this at the moment).
I have 2 servers which I though were synchronized (dev and live) but the "News System" (extension key "news") makes something different.
In the dev server this line
<f:format.date format="%A">{newsItem.datetime}</f:format.date>
outputs "Freitag", as expected (Thats friday in German)
But in the Live Server, it outputs %AM. Which is even weirder is that l (alone, without %) outputs "Friday" in English.
I've checked all the configurations I've seen and I cant seem to find where the difference between the systems is.
Any idea?
TYPO3 is using DateTime::format (http://de2.php.net/manual/en/datetime.format.php) to format the date. This method is using the same syntax of date() which is not using locales, so all output is english.
The only thing I can not explain is why your dev enviroment accepts %A to render the date. Are there different PHP-Versions? Which TYPO3 Version are you using? Get a look at /typo3/sysext/fluid/Classes/ViewHelpers/Format/DateViewHelper.php, you will get the answer there.
I just solved it! Turns out I had 4.7.7 in my live server, and that doesnt support stftime.
Funny, I never thought that such an important feature would be added in an 4.7.X update...
I'm using toLocalizedTime to output a date, as below
<span tal:content="python:here.toLocalisedTime(date.get('start_date'))"/>
This outputs eg. 2007/08/02, I'm just curious as to how one would alter the output so that it reads 02/08/2007
I'm not having much luck finding much info on toLocalizedTime, would someone point me in the right direction?
This depends on whether you have English selected as the site language (Site Setup >> Language). If so, then the default settings are used. You can change the defaults by dropping down into the ZMI, then into 'portal_properties', then 'site_properties'. The fields to change are either 'localTimeFormat' or 'localLongTimeFormat' depending on whether you pass in 'long_format=1' to the toLocalisedTime function.
If on the other hand, you have translations set up, the format may instead be pulled from the translation file for the locale selected. I'm not sure what is the easy way to change the format in this case (other than switching the site back to English). I guess you can register your own translation file but I've never needed to do that so you're going to have to look up the details.
Date string formatting follows the Python rules (http://docs.python.org/library/time.html#time.strftime).
Perhaps even more detail than you need:
here.toLocalizedTime()
is defined in the plone browser view at...
CMFPlone/browser/ploneview.py
which looks up the 'translation_service' utility, to call its 'ulocalized_time' function, defined at...
CMFPlone/TranslationServiceTool.py
which itself calls the 'ulocalized_time' function defined at...
CMFPlone/i18nl10n.py
As always, you can learn interesting things by grepping the source code ;-)
For an up to date answer for Plone 4.3 (after going through the source code)
These fields are now in the registry found at:
http://localhost:8080/yoursite/portal_registry
Then filter on "i18nl10n", which should give you the 4 fields you need to change.