.ts converted from .tvwiz not working on U4

[kentdorf72]

have a DP-P2 - save files as .tvwiz on a portable USB
thought it was time to use the U4 to be able to watch saved Beyonwiz files & MP4 (some mp4's don't play on the DP-P2)
as the U4 doesn't support .tvwiz, converted to .ts via WizFX version 1.0.2.3
U4 does not play many of the converted files - just site on 0.00 on time bar
pause / play icon changes if button pressed - apart from that the screen remains black

[MrQuade]

If you have Top/tailed those recordings, then the wiz will have problems with those.

You may need to re-edit then using a tool like videoredo and then run the reconstructapsc plugin over them to restore the correct indexing information.

Have a search for top and tail in the T series forums for some history on this.

[Grumpy_Geoff]

"U4 won’t play DP-S1 top edited, YARDWiz & WizFX converted .ts recordings until T2 does."

Being topped on the DP-series and then converted to .ts file format is the problem - incorrect packet alignment at the beginning of the stream.
See page 2.
The T-series can handle them, the U-series can't (perhaps the V-series too).
VideoReDo's Quick Stream Fix does "fix" the issue of the incorrect transport stream packet alignment.

[Paul_oz53]

I reencoded some of my old DP P2 recordings to MP4 with handbrake. Didn't always work but it is worth a try.

[kentdorf72]

top / tailed?
i guess some files have been edited to remove from the beginning to start of movie and ending of the movie to remove unwanted file, and others have had the wanted movie to be "cut out A ->B to a new file"
which is the best way to do it?
and what about when the half time adverts are cut out - will the U4 struggle to play at the start of the second half of the footie?

[kentdorf72]

why the hell didn't Beyonwiz make a PVR that plays it's own proprietary format??

as U4 is Linux based - can someone write a plug in or something that lets you watch Beyonwiz files on a Beyonwiz?

or what about the new V2?
or will that become a similar boat anchor to the U4?

[raymondjpg]

top / tailed?
i guess some files have been edited to remove from the beginning to start of movie and ending of the movie to remove unwanted file, and others have had the wanted movie to be "cut out A ->B to a new file"
which is the best way to do it?
and what about when the half time adverts are cut out - will the U4 struggle to play at the start of the second half of the footie?

I guess what others are saying here is, if you still have access to the unedited/uncut tvwiz files, then convert those to .ts files and hopefully they will be playable and could be edited on the U4.

[MrQuade]

why the hell didn't Beyonwiz make a PVR that plays it's own proprietary format??

Those files aren't a proprietary format, they are just .TS files that the DP series happen to break too into .tvwiz chicks to make them easier for the old boxes to work with.

The U4 video drivers have an issue with the way the old dp series wiz boxes malformed the recordings when they edited then. The T series boxes drivers handle them better.

Not 100% sure how the v series drivers handle them as it is a completely different architecture.

as U4 is Linux based - can someone write a plug in or something that lets you watch Beyonwiz files on a Beyonwiz?

The solution is to fix the broken files as-per the linked thread provided by Grumpy Geoff.

[raymondjpg]

The solution is to fix the broken files as-per the linked thread provided by Grumpy Geoff.

I had a good look at that thread and it wasn't readily apparent to me what the fix was other than play them in a T2 first. Possibly a modified version of Yardwiz...?

Anyway I took a look at sub3r's 2 second test file test-12c 2018-01-25_1-14500.ts. It definitely did not play untouched in my U4. I tried Netmask's suggestion running it through TSDoctor and that made the file playable. That wouldn't be much help to OP unless prepared to pay for a license, quite pricey at 34.90 Euro. Following another suggestion to use makeMKV I simply muxed the unplayable .ts file into a MKV container using the latest version of MKVToolNix GUI. The resulting mkv file was playable in my U4.

I have no idea if test-12c 2018-01-25_1-14500.ts is typical of files edited in the P/S series. Possibly not. Also, if it is, why simply muxing to a MKV was not posited as a solution in the first place. Possibly I'm missing something crucial here.

[kentdorf72]

I guess what others are saying here is, if you still have access to the unedited/uncut tvwiz files, then convert those to .ts files and hopefully they will be playable and could be edited on the U4.

Unfortunately files have already been edited

at least know what to do from now - convert to ts then edit on U4
doesn't help with the other files & no desire to spend many hours rooting around trying to get the previously edited & saved files to work

[raymondjpg]

I guess what others are saying here is, if you still have access to the unedited/uncut tvwiz files, then convert those to .ts files and hopefully they will be playable and could be edited on the U4.

Unfortunately files have already been edited

at least know what to do from now - convert to ts then edit on U4
doesn't help with the other files & no desire to spend many hours rooting around trying to get the previously edited & saved files to work

OK. See my latest post (above). Probably best to wait for someone to respond first, but if you like just try muxing one of your unplayable .ts files in to a mkv container with MKVToolNix GUI. It's free.

[Grumpy_Geoff]

The solution is to fix the broken files as-per the linked thread provided by Grumpy Geoff.

I had a good look at that thread and it wasn't readily apparent to me what the fix was other than play them in a T2 first. Possibly a modified version of Yardwiz...?

I stated -

VideoReDo's Quick Stream Fix does "fix" the issue of the incorrect transport stream packet alignment.

I also stated it in that linked thread.

Anyway I took a look at sub3r's 2 second test file test-12c 2018-01-25_1-14500.ts. It definitely did not play untouched in my U4. I tried Netmask's suggestion running it through TSDoctor and that made the file playable. That wouldn't be much help to OP unless prepared to pay for a license, quite pricey at 34.90 Euro. Following another suggestion to use makeMKV I simply muxed the unplayable .ts file into a MKV container using the latest version of MKVToolNix GUI. The resulting mkv file was playable in my U4.

I have no idea if test-12c 2018-01-25_1-14500.ts is typical of files edited in the P/S series. Possibly not. Also, if it is, why simply muxing to a MKV was not posited as a solution in the first place. Possibly I'm missing something crucial here.

If TS-Doctor fixes it, and kentdorf72 doesn't have too many affected recordings, he may want to use the 30-day free trial of TS-Doctor and work over those recordings.
Otherwise, as you state, use MKVToolNix GUI to produce an MKV file.
But it sounds like he's not interested in fixing them up.

If kentdorf72 wants to keep recording on the DP-series and edit those files to remove commercials, I'd be using TS-Doctor or VideoRedo on a PC for that editing.

I'm not sure if prl ever released a new version of getWizPnP that contains the fix for transport stream packet alignment. I'm not even sure the fix would deal with mis-aligned packets from in-stream editing. If it did, and if he did a release, kentdorf72 would need to use that new version in-place of the version that comes with YARDWiz.

[sub3R]

The following may or may not help those in a similar predicament that I was in (see Geoff's previous link).

Quite a while ago I ran all my DP-S1’s YARDWiz converted to .ts edited recordings through TSDoctor to improve how they played on the U4 (thanks to netmask for suggesting TSDoctor). Except for some seeking problems on some of the recordings they were acceptable.

I did this after playing enough of the edited .ts recording on the T2 to create a .meta file. The .meta file was copied along with the .ts recording to a share on the PC’s external HDD for playback from the U4 over the LAN.

Some recordings I had previously converted to .mpg format. For those I ran through Avidemux before running through TSDoctor.

I was inspired to use Avidemux by a post I found on this forum, but I can’t find that post or remember who posted it (thanks to whoever posted it). It was mainly instructions on how to edit T2 .ts recordings on a PC using Avidemux. I kept a copy of that post which I’ve re-posted in part below in dark red:

• I copy the .ts file from the Beyonwiz to the laptop hard drive for easier editing.
• Then I edit the .ts file using free Avidemux software. It is quite easy to trim the ends and to remove commercials and unwanted sections in Avidemux, as long as you remember to set the cutpoints at keyframes by using the keyframe buttons.
• Before saving the file, ensure that the Video Output option and the audio Output option are both set to Copy, and the Output Format is set to Mpeg TS Muxer (ff). This retains the original file quality and also speeds up the saving process as you are just cutting out sections rather than re-encoding the entire file.
• Save the new .ts file, and then change the name of the new file to match the existing file on the Beyonwiz. It’s a good idea to keep the original file saved somewhere just in case you’ve stuffed up the editing.
• Now copy the .ts file back to the Beyonwiz.
• And now for the magic bit that makes it work. Delete the .cuts file, the .meta file, the .ap file and the .sc file.
• The Beyonwiz will rebuild the .cuts file and the .meta file (and doesn’t seem to need the .ap file or the .sc file). If you don’t do this, the Beyonwiz assumes the file is still the same length, which screws up the playback. The program information is in the .eit file which you haven’t touched, so when you open up the video in Beyonwiz, the EPG movie/episode information is still there.

The following was my procedure for converting .mpg recordings that won't play on the U4 (mainly those that were originally topped & tailed on the DP-S1):

Use Avidemux set as follows.

• Video output: Copy
• Output format: Mpeg TS Muxer (ff)
• Configure: VBR muxing ticked
• Open the mpg recording to be encoded & it will begin indexing. When finished indexing click 'File > Save' & it will encode & save the recording as .ts

Then using TS Doctor.

• Open the above ts recording (or a .ts recording that won't seek on the U4) & the recording will be analysed. 'Save new file' (bottom right) & it will clean the transport stream & save the recording with '_fixed.ts' as part of the recording name. Any errors & warnings will be listed in a separate window & in the log file.

Note: 'Tas Enjoy 05.mpg', which was taken from a DVD, had no audio after running through Avidemux with the above settings (TS Doctor picked this up). I had to set Audio output to either MP3 (lame) or AC3 (Aften) - the later by Aften was recommended. Audio output Configure for AC3 (Aften) defaults to 128 kbps which is too low, so 384 kbps was recommended. I used 448 kbps.

[kentdorf72]

Have thought of one way to do it - just take bl00dy months
connected DP-P2 HDMI Out & connected to U4 HDMI In - press play on one & record on the other
am testing it as we speak (ok - write)

before i spend the next 18 months copying everything this way - anyone know of the best settings on the U4?
i.e. frequency / bitrate blah blah
don't want to spend yonks doing it like this only to find out that I should have used different U4 settings

this'll leave some previously reconfigured .ts files that wont work this waybecause the DP-P2 wont play them but beats rooting around with every video

[sub3R]

That would probably be the slowest way. I did try it as did Paul_oz53. See here. I can’t remember the settings I used.

TS Doctor is very quick if you use the save option.

[raymondjpg]

I stated -

VideoReDo's Quick Stream Fix does "fix" the issue of the incorrect transport stream packet alignment.

I also stated it in that linked thread.

OK, a similar solution to use of TS Doctor. I didn't try it, but I have generally found quick stream fix to be less effective at fixing up transport stream anomalies than TS Doctor, with generous doses of lost frames.

If TS-Doctor fixes it, and kentdorf72 doesn't have too many affected recordings, he may want to use the 30-day free trial of TS-Doctor and work over those recordings.
Otherwise, as you state, use MKVToolNix GUI to produce an MKV file.
But it sounds like he's not interested in fixing them up.

I didn't get that impression at all. More that he didn't want to spend a lot of time on it. Your suggestion to use the 30-day free trial of TS-Doctor would get around the issue in the immediate term. MKVToolNix GUI would be a longer term solution, if it works for him, and in my view just as simple and convenient as TS-Doctor with mkv as a more than acceptable video file format for the more recent BW series.

If kentdorf72 wants to keep recording on the DP-series and edit those files to remove commercials, I'd be using TS-Doctor or VideoRedo on a PC for that editing.

So would I, but it costs.

I'm not sure if prl ever released a new version of getWizPnP that contains the fix for transport stream packet alignment. I'm not even sure the fix would deal with mis-aligned packets from in-stream editing. If it did, and if he did a release, kentdorf72 would need to use that new version in-place of the version that comes with YARDWiz.

I wouldn't bother if MKVToolNix GUI does the job. There must be a dwindling population of P/S series out there and it doesn't seem to me to be worthwhile trying to fix something up that is fast becoming obsolete.

[raymondjpg]

Have thought of one way to do it - just take bl00dy months

Looks like a TS Doctor trial or MKVToolNix GUI will do the job. The former has a batch processing command line feature - "TSDoctor.exe" "D:\recording\*.ts" Autofix "D:\archive\" - from the help file. MKVToolNix GUI doesn't have batch processing capability but you can add to the job queue then leave the application to process all your files automatically.

[Grumpy_Geoff]

If TS-Doctor fixes it, and kentdorf72 doesn't have too many affected recordings, he may want to use the 30-day free trial of TS-Doctor and work over those recordings.
Otherwise, as you state, use MKVToolNix GUI to produce an MKV file.
But it sounds like he's not interested in fixing them up.

I didn't get that impression at all. More that he didn't want to spend a lot of time on it. Your suggestion to use the 30-day free trial of TS-Doctor would get around the issue in the immediate term. MKVToolNix GUI would be a longer term solution, if it works for him, and in my view just as simple and convenient as TS-Doctor with mkv as a more than acceptable video file format for the more recent BW series.

I got the impression from -

doesn't help with the other files & no desire to spend many hours rooting around trying to get the previously edited & saved files to work

If I was kentdorf72 and planning on just using the MKVToolNix GUI method, then I'd be testing that method on a few recordings that have had edits applied to remove ads and half-time breaks -

and what about when the half time adverts are cut out - will the U4 struggle to play at the start of the second half of the footie?

[Paul_oz53]

That would probably be the slowest way. I did try it as did Paul_oz53. See here. I can’t remember the settings I used.

TS Doctor is very quick if you use the save option.

Indeed, I did that with a few too. Since have had the P2 fixed - thanks to Warkus!

See my settings as follows:

HDMI settings.jpg (69.3 KiB) Viewed 6369 times

For the U4 you could use 1920x1080p.

[MrQuade]

Don't bother re-recording the files in real-time, that's insane.

Also, the HDMI recording will result in a certain drop in quality due to the re-encoding, but I am assuming you are aware of that.

By far the quicker and easier equivalent to that is to simply re-encode all the files using Handbrake or similar. You will have the same loss in quality that you would see with a HDMI recording, but it will be orders of magnitude faster.

Handbrake will completely re-encode the file as H.264 and you can simply batch feed it all the input files and leave it to chew on them for as many hours as that takes.

This way you don't have to wait literal months for every file to play in real-time, and you also don't need to mess about with manually editing each and every file as you would with those other video editing tools.

This is exactly how I copied all of my DP recordings over when I switched years ago. I did it primarily to reduce the file size as I didn't particularly care about the fidelity of the recordings.

[prl]

I'm not sure if prl ever released a new version of getWizPnP that contains the fix for transport stream packet alignment. I'm not even sure the fix would deal with mis-aligned packets from in-stream editing. If it did, and if he did a release, kentdorf72 would need to use that new version in-place of the version that comes with YARDWiz.

I didn't release it. It only dealt with misalignment at the start of the file, and the code isn't set up in a way that makes it easy to do the fixups in the body of the recording.

Part of the reason for that is that last time I made a beta available, there seemed to be issues with the Windows build of getWizPnP, and that's probably the most-used version.

In the meantime, some software rot has also crept in: for example, MacOS YARDWiz is 32-bit, so even if I made a new version of getWizPnP for MacOS, it wouldn't work in YARDWiz on Catalina, which supports only 64-bit executables.

Does anyone know for sure that edits in the body of the recording cause problems?

IIRC, the issue is that edits on the DP series Beyonwiz don't respect packet boundaries in the data stream (packets are 188 bytes).

On the U4, the drivers won't play a recording where the .ts file doesn't start with a "start of packet byte" 0x47. The actual requirements may in fact be more complicated.

If the recording is played on a Beyonwiz that can cope with an incomplete packet at the start of the .ts file, then playing that puts the cached packet ids (PIDs) into the .ts.meta file of the recording, and if the recording (with its .ts.meta file) is played on the U4 it will (usually?) play.

That means that if you can jig up a .ts.meta file with the right cached PIDs, you may be able to play the recording without doing anything more than creating a small ASCII file.

Unfortunately, the PIDs used vary between broadcasters for the same packet streams, and not all recordings from the same broadcaster have the same set of PIDs, because different PID cache entries are used for different audio types, and the entry for the subtitle packet stream PID may or may not me present.

That means it's difficult in general to make a suitable set of cache entries except by playing the recording on a different device

[sub3R]

By far the quicker and easier equivalent to that is to simply re-encode all the files using Handbrake or similar. ...
...
This way you don't have to wait literal months for every file to play in real-time, and you also don't need to mess about with manually editing each and every file as you would with those other video editing tools.

I don’t know if handbrake is any better than VidCoder (VidCoder uses handbrake as its encoding engine). But I didn’t have much success with VidCoder with the YARDWiz top & mid edited .ts files from the DP-S1. There was no manually editing with TS Doctor. And if Avidemux is used to go from .mpg to .ts it is almost instantaneous providing the recording isn’t being edited.

Perhaps using handbrake would have achieved the same but I didn’t try it.

And yes, re-recording the recordings in real times will take ages.

[Grumpy_Geoff]

Does anyone know for sure that edits in the body of the recording cause problems?

Paragraphs 2 & 3 in the post from Dennis here suggests so (at least to me).

[sub3R]

Does anyone know for sure that edits in the body of the recording cause problems?

I thought you found that it did, or was that what you suspected?

A couple of my mid edited recordings had problems with skipping. I'm not certain but I think a couple also froze at the edited section. I found that out later when my testing in that topic was finished.

[Grumpy_Geoff]

By far the quicker and easier equivalent to that is to simply re-encode all the files using Handbrake or similar. ...
...
This way you don't have to wait literal months for every file to play in real-time, and you also don't need to mess about with manually editing each and every file as you would with those other video editing tools.

I don’t know if handbrake is any better than VidCoder (VidCoder uses handbrake as its encoding engine). But I didn’t have much success with VidCoder with the YARDWiz top & mid edited .ts files from the DP-S1. There was no manually editing with TS Doctor.

TS-Doctor has the batch processing feature, as raymondjpg pointed out.

[sub3R]

Paragraphs 2 & 3 in the post from Dennis here suggests so (at least to me).

You are a wizard Geoff at finding things in this forum.

[sub3R]

TS-Doctor has the batch processing feature, as raymondjpg pointed out.

Exactly. What I meant was I didn’t do any manually editing with TS Doctor.

[MrQuade]

But I didn’t have much success with VidCoder with the YARDWiz top & mid edited .ts files from the DP-S1.

What do you mean you didn't have much success?

As in the files didn't re-encode, or that the re-encoded files still couldn't skip?

[Grumpy_Geoff]

Paragraphs 2 & 3 in the post from Dennis here suggests so (at least to me).

You are a wizard Geoff at finding things in this forum.

Landing on that post was a fluke, I was searching on Avidemux.

[sub3R]

What do you mean you didn't have much success?

As in the files didn't re-encode, or that the re-encoded files still couldn't skip?

I can’t remember exactly, it was a fair while ago. I think they still didn’t skip correctly. I remember what VidCoder didn’t fix, TS Doctor did.

TS Doctor didn’t fix every recording but it fixed about 98% of them. They all played correctly, it’s just that a couple still had problems with seeking.

[kentdorf72]

U4 hung up yesterday, seems to do that from time to time if trying to look at a converted file that it cannot read.
every button push brings up the square icon with the line thru it in the top middle of the screen
factory reset - when trying to get the network configured (had this issue multiple times before yesterdays reset) - configure network - (tried both auto & manual) - system auto selects WPA2 - ok to continue - yes - network configuration active - activated - at auto timeout system goes to test network - network not working

yesterday network was operational as software updates were performed

ALSO
yesterday was able to run the DP-P2 HDMI out to U4 HDMI IN - but after resetting she's cactus
U4 - press the [WizTV] HDMI IN button - on screen HDMI / 1080p / 50Hz
DP-P2 - config - A/V output - HDMI - auto - message box of HDMI not connected
thus no TV via U4 HDMI input
if push TV Out on DP-P2 - goes to HDMI then scrolls around until auto A/V Input acain

no wiring has been changed, unplugged / plugged HDMI cables again

can't remember if i did anything differently yesterday to get it to work, certainly didn't have this many headaches

[MrQuade]

U4 hung up yesterday, seems to do that from time to time if trying to look at a converted file that it cannot read.
every button push brings up the square icon with the line thru it in the top middle of the screen
factory reset - when trying to get the network configured (had this issue multiple times before yesterdays reset) - configure network - (tried both auto & manual) - system auto selects WPA2 - ok to continue - yes - network configuration active - activated - at auto timeout system goes to test network - network not working

yesterday network was operational as software updates were performed

What updates? I don't think any updates have been pushed out recently, unless you have enabled a 3rd party repository (such as IanSav's repository for picons)

ALSO
yesterday was able to run the DP-P2 HDMI out to U4 HDMI IN - but after resetting she's cactus
U4 - press the [WizTV] HDMI IN button - on screen HDMI / 1080p / 50Hz
DP-P2 - config - A/V output - HDMI - auto - message box of HDMI not connected
thus no TV via U4 HDMI input
if push TV Out on DP-P2 - goes to HDMI then scrolls around until auto A/V Input acain

no wiring has been changed, unplugged / plugged HDMI cables again

can't remember if i did anything differently yesterday to get it to work, certainly didn't have this many headaches

A factory reset doesn't really do much except load the factory default settings back onto the Wiz. It doesn't reset the Wiz back to a "factory fresh" state with original software etc.
You may find that there has been some corruption of the software on the Wiz that goes beyond the settings, and for that, you need to install the firmware from scratch from USB. This is the only sure fire way to ensure that the Wiz is in a "factory fresh" state.

Sometimes yanking power on the Wiz when it is still doing something can result in filesystem corruption, and sometimes the only way to fix that is to load firmware from USB.

I recommend that you install a fresh copy of the latest 19.3 firmware image, and go from there.

[kentdorf72]

downloads?
software manager - check for updates now i think was selected & it did it's thing

[Grumpy_Geoff]

software manager - check for updates now i think was selected & it did it's thing

What firmware version are you running?

[kentdorf72]

fyi - tried the usb firmware upgrade - didn't work as i think it was a new usb stick - BW docs recommends small vol old usb's
anyway - pressed [plugin] button - software management - think software restore
and i got HDMI input signal
go figure

[kentdorf72]

What firmware version are you running?

if that's in the info - about section
Version 17.5
build 20190207
revision 20190207

[Grumpy_Geoff]

revision 20190207

That's old.
https://beyonwiz.com.au/downloads/

[kentdorf72]

as the U4 is linux, do you have to "un-mount" a USB to remove it from the file system, or is just unplugging it ok?
haven't seen an "un-mount" or "eject" option
but with so many unlisted features avail that aren't in the manual - who knows!

[prl]

as the U4 is linux, do you have to "un-mount" a USB to remove it from the file system,

Yes. And it's not just U*ix systems: it's essentially the same thing as "Safely remove device" in Windows.

or is just unplugging it ok?

No.

haven't seen an "un-mount" or "eject" option

In live TV, MENU>SimpleUmount.

[maverick#1]

kentdorf72, I had the same problem as you. I went through the same steps (copy from DP PVR to USB, convert .tvwiz folder to .ts using WizFX) and found some files would play on my U4 and others wouldn't.

I found a very simple solution: rename the file from "<filename>.ts" to "<filename>.mpg".

I don't know if it will work on every file, but it has worked on every DP recording that wouldn't play back on my U4. To be sure, I just made a short 5 min recording on SBS Viceland HD (1920 x 1080 res). I then chopped about 30 secs off the beginning and end (topped & tailed), then chopped a 30 sec bit out about 30 secs into the topped & tailed file and chopped anoher 30 secs out near the end. I wanted to see if edits within the file (like editing out ads) caused problems. The .ts file wouldn't play on my U4. Like you said, the time elapsed stayed at 0.00 and there was no sound. On the other hand, when I renamed it with a .mpg file extension it played back fine. The sound would go slightly out of sync where the internal edits were, but if I jumped forward then immediately jumped back the same amount (eg 10s forward then 10s back), as long as I didn't jump back to before the edit, the sound would be back in sync.

Give it a go and see if it works with your .ts files that won't play. If it works, it will save you a lot of time.

Oh, and just in case it makes a difference (and in case I change my signature), the firmware version I'm using is 17.5, Build 20180417.

[prl]

Was the original .tvwiz recording (it's not a single file) edited before you copied it?

[maverick#1]

Was the original .tvwiz recording (it's not a single file) edited before you copied it?

Yep, all edits were performed on my P2 before being copied to an external hard drive. The only thing I did on the PC was use WizFX to convert the files in the .tvwiz folder to a single .ts file. Okay, that's not quite true. I made a copy of the .ts file and changed the file extension of the copy to .mpg on the PC too. It was easier to do it on a PC than on the U4. But I have also changed the file extension of P2 .ts files on the U4 as well (using Menu > Sources/Files I think, cos I don't think you can change the file extension from the Media file list) and this worked too. No processing was done on the PC and it's worked with both HD and SD recordings from many different channels and networks.

[prl]

Was the original .tvwiz recording (it's not a single file) edited before you copied it?

Yep, all edits were performed on my P2 before being copied to an external hard drive.

If you trimmed off the start padding, that's the source of the problem. If you have a different model Beyonwiz, the same .ts files will play on them. And if you copy the .ts file with its .meta file back to the U4, it will play there, too.

If you don't have another model Beyonwiz, you are likely to be able to play the files if you use a PC editor to trim just a small amount from the start of the recoding: e.g. trim everything before the first I-frame, for a minimal edit that won't affect what is possible to see on playback.

[peteru]

If I understand correctly, maverick#1 is saying that simply renaming the file to change the .ts extension to .mpg extension is a workaround for the unplayability of the file. Since we know that the issue is related to bad TS packet alignment, this information provides a useful clue as to what may be required to address the issue. There must be something in the .ts code path that prevents correct stream parsing, whereas the .mpg code path is not affected. Looking for the differences between .ts and .mpg file handling is likely to show a path towards the root cause and a possible fix.

[peteru]

BTW: I'm not volunteering myself to do the investigation at this stage. Happy to chime in with advice, but too busy to take the lead.

[adoxa]

There's the obvious one: .ts is played by the DVB driver, .mpg is played by GStreamer. It could be as simple as skipping initial data until a sync byte is found. But I'm not volunteering, either (unless it occurs on the V2?).

[MrQuade]

There's the obvious one: .ts is played by the DVB driver, .mpg is played by GStreamer. It could be as simple as skipping initial data until a sync byte is found. But I'm not volunteering, either (unless it occurs on the V2?).

I just tried Grumpy Geoff's sample file that he posted in the original thread, and the V2 doesn't suffer from this issue.

So it looks like this only happens on a U4.
Renaming .mpg can work around the issue, presumably because of the gstreamer/dvb difference.
Generating a valid set of metadata files on a Tx or V2 will also allow the U4 to play the file.

[prl]

ISo it looks like this only happens on a U4.

Yes, from the last time this was discussed, I'm pretty sure it's specific to the U4.

Generating a valid set of metadata files on a Tx or V2 will also allow the U4 to play the file.

The problem is that the first time a recording is played, the code looks for the Packet Ids (PIDs) for the data streams in the recordings and fails if they can't be found. When playback finishes the PIDs are written to the 8th line of the recording's .meta file (the cached pids are the entries with the "c:" tag).

Once those entries have been cached in the .meta file, those values are used rather than searching for them each time the recording is played.

On the U4, if the recording doesn't start on a packet boundary, the search for the PIDs fails, and the recording doesn't play.

However, if the recording as already been played on another Beyonwiz and copied to the U4 (with the .meta file) or played from a share where another Beyonwiz has played it first, the .meta file will contain those cached PIDs and will play normally on the U4.

That's why I suggested that a minimal edit on a PC might fix that problem. restoreapsc would need to be run on that edited recording once it was copied back (or edited in place on a share).

[MrQuade]

Yes, from the last time this was discussed, I'm pretty sure it's specific to the U4.

I was just verifying that the V2 was also not affected. V2 was not around the last time this came up.