Strange entries in Media details

peterworks

Ye Olde Bowler
I recorded the Marlow Murder Club last night. I then cut and pasted it to the already created folder with the first program in it. On looking at the media details these entries are at the bottom:
[mpeg2video @ 0x48be60] Invalid frame dimensions 0x0.
[mpegts @ 0x4428c0] start time for stream 2 is not set in estimate_timings_from_pts
[mpegts @ 0x4428c0] PES packet size mismatch
[mpegts @ 0x4428c0] Could not find codec parameters for stream 2 (Audio: mp3 (mp3float) ([3][0][0][0] / 0x0003), 0 channels, fltp): unspecified frame size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Input #0, mpegts, from '/media/My Video/The Marlow Murder Club/The Marlow Murder Club_20240307_2000.ts':
Duration: 01:58:20.95, start: 4286.482122, bitrate: 2503 kb/s
Program 12928
Metadata:
service_name : 5STAR
service_provider:
Program 12944
Metadata:
service_name : TalkTV
service_provider:
Program 12952
Metadata:
service_name : YAAAS!
service_provider:
Program 12960
Metadata:
service_name : Pop Player
service_provider:
Program 12968
Metadata:
service_name : FailArmy/PetCollective
service_provider:
Program 12992
Metadata:
service_name : 5USA
service_provider:
Program 13008
Metadata:
service_name : Dave ja vu
service_provider:
Program 13024
Metadata:
service_name : Channel 5+1
service_provider:
Program 13120
Metadata:
service_name : QVC
service_provider:
Program 13144
Metadata:
service_name : MBC
service_provider:
Program 14384
Metadata:
service_name : Blaze
service_provider:
Program 14388
Metadata:
service_name : Blaze+1
service_provider:
Program 14416
Metadata:
service_name : QVC2
service_provider:
Program 14448
Metadata:
service_name : TRUE CRIME
service_provider:
Program 14456
Metadata:
service_name : TRUE CRIME XTRA
service_provider:
Program 14464
Metadata:
service_name : WildEarth
service_provider:
Program 14480
Metadata:
service_name : LEGEND
service_provider:
Program 14488
Metadata:
service_name : TCC
service_provider:
Program 14688
Metadata:
service_name : Absolute Radio
service_provider:
Program 15016
Metadata:
service_name : Sonlife
service_provider:
Program 15064
Metadata:
service_name : On Demand 365
service_provider:
Program 15200
Metadata:
service_name : ADULT Section
service_provider:
Program 15448
Metadata:
service_name : Channelbox
service_provider:
Program 15480
Metadata:
service_name : UK RADIO PORTAL
service_provider:
Program 15576
Metadata:
service_name : GREAT! action
service_provider:
Program 15592
Metadata:
service_name : TJC
service_provider:
Program 15864
Metadata:
service_name : ITVBe+1
service_provider:
Program 15920
Metadata:
service_name : ITV4+1
service_provider:
Program 15952
Metadata:
service_name : ITV2+1
service_provider:
Program 16016
Metadata:
service_name : ITV3+1
service_provider:
Program 16112
Metadata:
service_name : 5ACTION
service_provider:
Program 16200
Metadata:
service_name : Ketchup TV
service_provider:
Program 16208
Metadata:
service_name : Drama
service_provider:
Stream #0:0[0x19d1]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, progressive), 544x576 [SAR 32:17 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:1[0x19d2](eng): Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 128 kb/s
Stream #0:2[0x19d3](eng): Audio: mp3 ([3][0][0][0] / 0x0003), 0 channels, fltp (visual impaired) (descriptions) (dependent)
Stream #0:3[0x19d6](eng): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)
Program 16216
Metadata:
service_name : Ketchup Too
service_provider:
Program 16224
Metadata:
service_name : Alaraby Network
service_provider:
Program 16240
Metadata:
service_name : ROK
service_provider:
Program 16248
Metadata:
service_name : Revelation TV
service_provider:
Program 16256
Metadata:
service_name : God TV
service_provider:
Program 16264
Metadata:
service_name : 3ABN
service_provider:
Program 16272
Metadata:
service_name : AmazingDiscoveries
service_provider:
Program 16278
Metadata:
service_name : Al Jazeera English
service_provider:
Program 16284
Metadata:
service_name : Al Jazeera Arabic
service_provider:
Program 16296
Metadata:
service_name : ASHARQ NEWS
service_provider:
Program 16298
Metadata:
service_name : Real Crime
service_provider:
Program 16304
Metadata:
service_name : AL ARABIYA
service_provider:
Program 16310
Metadata:
service_name : Shots!
service_provider:
Program 16316
Metadata:
service_name : Zee World
service_provider:
Program 16322
Metadata:
service_name : NHK WORLD
service_provider:
Program 16328
Metadata:
service_name : Newsmax
service_provider:
Program 16334
Metadata:
service_name : Mech+
service_provider:
Program 16340
Metadata:
service_name : NYX
service_provider:
Program 16346
Metadata:
service_name : Amazing Facts
service_provider:
Program 16352
Metadata:
service_name : Moochi
service_provider:
Program 16358
Metadata:
service_name : TV Extra
service_provider:
Program 16364
Metadata:
service_name : Together TV
service_provider:
Program 16370
Metadata:
service_name : FRANCE 24
service_provider:
Program 16376
Metadata:
service_name : Nosey
service_provider:
Program 15176
Metadata:
service_name : 696
service_provider:
Program 15208
Metadata:
service_name : 695
service_provider:
I have not seen this before though, of course, I don't look at the details that often.
It plays fine - any ideas ?
 
I recorded the Marlow Murder Club last night. I then cut and pasted it to the already created folder with the first program in it. On looking at the media details these entries are at the bottom:

I have not seen this before though, of course, I don't look at the details that often.
It plays fine - any ideas ?
Normal for this information to be in the original recording.
If you wish to remove it, you can use https://wiki.hummy.tv/wiki/Custom_Firmware_Package_Notes#Shrink_.28stripts.29
 
Not normal for it to be shown in the webif display
..
I've seen this issue when using WebIF to copy fileset from one directory to another. Media details on the destination fileset gives different result. Maybe it only occurs for a short while after the copy. (It could before it's completed the DLNA indexing?)

I misunderstood OP's initial post! I didn't realise it was the media details on WebIF.
 
Last edited:
Yes the .hmt file is present. I used to use shrink but, as I now have a large disk, I discontinued it.
I just checked again and the extra details have disappeared. Perhaps the indexing did sort it out.
 
It says so in the OP and where else would a normal non-expert go to look at recording details
I can recreate the symptoms exactly by deleting the .hmt file and looking at recording in webif.
That's one way of creating the symptom.
Another way is to look at the media file in WebIF after it's decrypted but before it gets a DLNA URL.
One way of testing for this is to
  • Turn off content share - Menu/Settings/System/Internet Setting/Content Share/off
  • WebIF/browse/My Video/select a short old decrypted recording/copy
  • Paste it to a different directory
  • WebIF/browse/My Video/select the old or new file to read the media details.
  • WebIF will mask the extraneous data for the old file but not the new one.
  • The only difference being old one was DLNA indexed and the new one isn't.
  • Turn on content share - Menu/Settings/System/Internet Setting/Content Share/on
  • Wait a few minutes, look again and the media details for both will be very similar
 
That's one way of creating the symptom.
Another way is to look at the media file in WebIF after it's decrypted but before it gets a DLNA URL.
One way of testing for this is to
  • Turn off content share - Menu/Settings/System/Internet Setting/Content Share/off
  • WebIF/browse/My Video/select a short old decrypted recording/copy
  • Paste it to a different directory
  • WebIF/browse/My Video/select the old or new file to read the media details.
  • WebIF will mask the extraneous data for the old file but not the new one.
  • The only difference being old one was DLNA indexed and the new one isn't.
  • Turn on content share - Menu/Settings/System/Internet Setting/Content Share/on
  • Wait a few minutes, look again and the media details for both will be very similar
That is very interesting, and would explain the OPs symptoms - the period between the recording being moved and it being reDLNA indexed.
But I cant really understand why the DLNA status should have an affect unless there is a bug in the Webif
The normal webif display uses the .hmt file contents not the .ts to populate the details display and the hmt is present whether or not the recording is DLNA indexed it only attempts to use the recording file details when there is no .hmt
You can display media details while a programme is still recording and that is before it is indexed.
 
That is very interesting, and would explain the OPs symptoms - the period between the recording being moved and it being reDLNA indexed...
Yes, I thought it looked like a good fit.
But I cant really understand why the DLNA status should have an affect unless there is a bug in the Webif
That may/may not be the issue. It's just my perception from tests and noticing the difference in WebIF.
It might be a small bug.
..
You can display media details while a programme is still recording and that is before it is indexed.
Maybe there is some exception processing for file in use and/or encrypted. Duplicating that process for freshly created files will probably work. But it's not a big deal because, as long as content share is on, the issue goes away shortly.

Edit: After some more tests, I think it's to do with WebIF, decryption and DLNA index.
Currently WebIF masks the extra info for files that are either encrypted or DLNA indexed.
So there may be a (usually small) window between decrypting and DLNA index during which WebIF will try to show the extra information.
 
Last edited:
I've fixed this properly this time (I hope) in 1.5.2-10.
It now copes with lone .ts files, lone .hmt files, a normal pair of .ts and .hmt files, non-native files and does the correct thing with ffprobe output and enabling the Play and Download buttons.
I guess the previous naffness was the result of evolution. Sometimes you need to start again. The difficulty is working out what the original intent was and how to correct it to what now makes sense to most/all people.
 
I've fixed this properly this time (I hope) in 1.5.2-10.
It now copes with lone .ts files, lone .hmt files, a normal pair of .ts and .hmt files, non-native files and does the correct thing with ffprobe output and enabling the Play and Download buttons.
I guess the previous naffness was the result of evolution. Sometimes you need to start again. The difficulty is working out what the original intent was and how to correct it to what now makes sense to most/all people.
The 'Show ,ts info' option of sidecar provides a much shorter and more useful view of the media details (including title and synopsis) than browse does for the no hmt case
1710087646565.png
versus
1710087480980.png

Would it be be possible to consider using this sidecar view in browse instead when there is no hmt, of course if the file has been shrunk even this information won't be available (perhaps Shrink should leave just the first set of epg info for the programme and strip the rest)
 
I now have a problem with installing webif-matthew-cutdown2.zip after the weif update to 10. I get:
Capture 10-03-2024 16_59_26.jpg

I have five favourites, the four 'main' channels and a MyTV which contains about 20 channels. When trying to show MyTV the epg now only shows BBC.

Edit: There appears to be no way to back out of this...
 
Last edited:
You'll just have to edit that file manually, as shown (use the WebIf file editor).
You can always back out of patches by using the "-R" switch to reverse them.
Anyway, there's another bug in that function which I didn't spot before.

Edit: Or you can run this from a command prompt:
sed -i 's/set ret ""/set ret "TV Radio HD SD"/' /mod/webif/lib/settings.class
 
Last edited:
Back
Top