I'm getting an 'APar_readX_noseek read failed' reading back a written file.

Issue #7 resolved
created an issue

Just trying out the latest version on Mac OS X v10.6.4 and I've hit upon a problem. On a few test files I have written some new tags, and all appears to go well. But then AtomicParsley will not read them back with the -t flag and instead reports:

{{{ APar_readX_noseek read failed, expect 12, got 8: No such file or directory }}}

The original file is read perfectly with the same command, but the output from AtomicParsley appears damaged. However, the file still plays and mp4info reports that the tags have been written correctly. The file cannot now be used again with AtomicParsley though. :(

Any clues?

Comments (13)

  1. Wez Furlong repo owner

    A bit hard to say what's going on here. It looks like one of the tags is telling AP to seek and then read 12 bytes, but it only read 8; presumably because it got to the end of the file.

    I have to confess to not being an expert with the file format (my involvement was mostly to make it work with large files).

    Are you comfortable with adding debugging to print out the file offsets and tags to try to find out where it's gotten busted?

  2. Anonymous

    @Andy Grant: I think I may have a solution for you. I was getting this same APar_readX_noseek error on some audio tracks I was trying to edit with AtomicParsley, but others were fine. I installed mp4v2 and ran the following command:

    mp4file --optimize myfile.m4a

    After that, AtomicParsley handled the file just fine. Granted, it would be nice if AtomicParsley could recover from the problem and just do whatever mp4file's optimize is doing to get around it, but this may be a viable workaround for you. It worked for me at least. YMMV

  3. remezen

    So, I have a file wich gives APar_readX_noseek read failed, expect 12, got 0: No error even trying to read (-t option). It was just converted with Handbrake. File is fine. The same after optimising with mp4file. I attached a torrent (file is 2.42Gb, sorry), will be seeding 24/7

  4. Prasand J.

    Initially the problem presents itself as:

    APar_readX_noseek read failed, expect 12, got 8: No such file or directory


    mp4file --optimize myfile.m4a

    Results in:

    APar_readX_noseek read failed, expect 12, got 0: No error

    Otherwise, the latter result occurs prior to optimization, and doesn't change after.

    I have not been able to obtain a 0.9.3, or 0.9.2 windows executable of the code, to test when the problem was introduced, but perhaps someone else can compile the code and do so. For now I assume that a newer writing method was introduced since 0.9.0 (perhaps the memory handling itself), as 0.9.0 succeeds on those problematic files.

    For my project, upon encountering the error the code reverts to using version 0.9.0. It then uses mp4tags for the data unsupported by 0.9.0. A less than optimal solution, but it works.

  5. Oleg Oshmyan

    @remezen, my torrent client still has not picked any peers (and I started the download about several hours after you posted the torrent), so it looks like that unfortunately is not going to work.

    Prasand, as I understand, you are getting these results on Windows; is your file over 2 GiB in size? Regarding versions, this error check was only introduced in 0.9.3, so even if earlier versions do not complain, it may be that the error occurs but they just ignore it.

    It seems that files larger than 2 GiB are actually still not supported on Windows. (This is bad. I will fix it.) However, the original poster reported getting this problem on Mac OS X, so there must be another bug hiding somewhere.

  6. Oleg Oshmyan

    I have pushed a fix (hopefully) for the original problem to my fork. (Should have written something like ‘see issue #7’ in the commit message, but it is now too late.) It is aimed specifically at resolving the ‘expect 12, got 8’ error. The best I can say about ‘expect 12, got 0’ so far is that it should never happen at all, even with the (actually only slightly) broken large file support on Windows.

  7. Oleg Oshmyan

    I have also pushed a fix for large file support on Windows. Oh, and I have also changed the error messages printed by APar_read*, so if you re-test and there are still errors, please provide the full error messages again.

  8. Oleg Oshmyan

    I am writing more and more comments… Anyway.

    I have finally understood how the broken large file support might have caused ‘expect 12, got 0’ (comparisons between integers of different signedness are unsigned). And my latest commit should have fixed it.

  9. Log in to comment