all
I got two streams such as Main and Dev. If I worked on Main and modified a file, called move.cs, for solving a problem, how can I merge move.cs to Dev. Since probably I have to change a lot of files on Main stream for correcting errors, it could be easy if the corrected files can be merged or copied to Dev stream, so that the same error can be solved on Dev stream, too.
Is there anyway to do it?
Thanks!
I assume that Dev is the child stream of Main.
From P4V graphical stream view, you can right click on the child stream, and select "Merge/Integrate to Dev...". By default it will try to merge from the parent stream up to parent #head revision.
More generally you have to use the p4 integrate command.
You can also shelf you changset in and unself it in another stream.
Related
I am using the command line tools of Perforce.
And with the p4 tool, I want to sync to a stream.
The problem is that I want to exclude a directory from my workspace.
If my work space was defined as a view, this would be possible with something like:
View:
//depot/Foo/... //Client/Foo/...
-//depot/Foo...bin/... //Client/Foo...bin/...
But the Stream: setting overrides the View: specification.
I have set the Stream using the command:
$ p4 client
I also looked into P4IGNORE mechanism, but this is of no use to my problem, as P4IGNORE will not influence the sync command.
I tried adding a Paths: command to my client spec, but that is not recognized in this context. I think it is used when specifying the stream, as done by the administrator of the depot?
This is exactly what virtual streams are for. :) Create a child of the stream with type virtual, and exclude the directory from the virtual child stream (via either Paths or Ignore in the stream spec). This will generate you a client view that is the desired subset of the parent stream.
https://www.perforce.com/blog/virtual-streams-windows-big-projects
I am new to Perforce "stream depots" and stuck at step 1. I am trying to create a workspace that includes only one folder from a huge stream depot.
Every time I try, it seems to want to download the entire stream, which is a huge amount of files. I can see now way to limit it to just one folder.
This is what virtual streams are for.
Create a new stream that is a child of the stream in question, with type "virtual", and specify its Paths as the single folder, e.g.:
Stream: //streams/just_the_facts
Parent: //streams/main
Type: virtual
Paths:
share path/to/the/facts/...
Now switch to that stream:
p4 switch just_the_facts
and you only have the files from the facts folder.
What I ended up doing was:
p4 set P4CLIENT=MyWorkspace then
p4 client -s -S //My/Stream to create the workspace.
Then p4 sync //My/Stream/just/the/dir/I/want...
TL;DR
I'm unsure the best way to recognise when encoding videos have finished with Chokidar. Given the different methods encoders build their video files, what's the best way to accomodate all of them?
Context
I've developed a workflow for our office that allows us to quickly queue encode jobs in Adobe Premiere Pro. To queue them locally, I made use of Premiere's CEP API. I can easily send a job to Adobe Media Encoder (on the same machine) and it will automatically encode the video file to the relative project directory. This works great.
To queue encode jobs onto LAN workstations, I've taken a different approach, as the CEP API doesn't allow for any extensibility beyond the local machine. Instead I made use of Adobe Media Encoder's watch folders to detect added Premiere project files to a subfolder on our NAS (everything is on the NAS). This works great too.
Unfortunately, I'm unaware of a way for the queued encodes to be output to the relative project directory in the same way queuing locally does. I'm trying to find a way to do this by watching a common directory and moving finished files.
Since each video filename I'm queuing has this structure:
"projectName_sequenceName_givenName_renderType.mp4/.mxf" I've been able to move the files with this information easily. However, I'm struggling to accomodate for the different methods different encoding processes use. Different encoders - X264, MainConcept H264, etc - encode to disk differently.
Using Chokidar, I watched how different encoders build their files:
Example #1:
If I start a DnXHR MXF encode, it will first create the final .MXF container and then fill it. When it finishes, it writes the sidecar .XMP file. If the encode fails or is cancelled, the sidecar file will not be written.
Example #2:
If I start a TMPG x264 encode, it will first create the final .mp4 container, then create a temporary file: '.mp4_00_' appended. It will then write some initial metadata to the final container, start encoding to the '.mp4_00_' and depending on file size, create additional temporary files, '_.mp4_01_', etc. Finally it writes some additional information to the container, then to the temporary files and then deletes the temporary files. If the encode fails or is cancelled, the files are deleted.
Example #3:
If I start a MainConcept H264 encode (Premiere's default), it will first create the audio temp file, in this case '.aac'. Then create another temp file '.mkv.md0'. Halfway through encoding, it will create the video container '.m4v', start encoding to that, create some more temporary files '.md7/md6', create the final container '.mp4', along with 'sbjo.tmp', copy the '.mkv' file and '.aac' into the '.mp4' container, add a '00' file, very quickly delete it and then finish writing the '.mp4' metadata. Some of this happens very quickly and Chokidar has not always picked it up. Unless the encoder is being inconsistent.
These are the three encode types I've observed, and they're the three we need and use. I suppose I could watch each of them differently, but my concern would be if we ever switched encoders, I'd have to rewrite the code to accomodate them. The watch folder feature that Adobe Media Encoder has recognises when files have finished encoding before attempting to use them. I haven't tested every format, but a good deal. Would Media Encoder be accomodating each unique encoding process? Simply polling locked files? Or is there something I'm missing?
The code I have currently works fine for DNxHR MXFs provided they don't fail or are cancelled. It struggles with the h264/x264 examples. Since the file is created and left untouched while encoding to the temporary files, chokidar will register 'add'. Since the file is locked the move fails. Obviously this works fine when simply copying or moving a finished video file.
const watcher = chokidar.watch(['Z:/NETWORKRENDER/Finished/*.{mp4,mxf}'], {
persistent: true,
// On start, works on existing files
ignoreInitial: false,
followSymlinks: true,
interval: 1000,
awaitWriteFinish: {
stabilityThreshold: 5000,
pollInterval: 20000
},
});
I need to merge the streams using commands in P4. can anyone help me with this? the two streams are parent child streams. I need to merge down from parent to child.
I'm typing this from memory, without actually trying it, but I think this is pretty close:
Switch your client workspace to the child stream, since that is the target of the merge: p4 client -s -S child
Sync your client, to make sure you're building and testing with the latest files: p4 sync
Merge the parent stream's changes into your child stream: p4 merge
Resolve any conflicts: p4 resolve
Build and test, to confirm that you're happy with the results
Submit the merged code to the child stream: p4 submit
Of course, make sure that you're working with the correct client workspace, as the correct user, etc., by running p4 set before you start this process, to look at your P4CLIENT, P4USER, etc. settings.
I have a video files in:
/home/private/movies/video1.mkv
/home/private/movies/video2.mkv
/home/private/movies/video3.mkv
I have hardlinks to those mkv files in:
/home/minidlna/videos/video1.mkv
/home/minidlna/videos/video2.mkv
/home/minidlna/videos/video3.mkv
My minidlna share is:
/home/minidlna
The video files show up on the minidlna cilent (my TV) after I do a full rescan of the minidlna share, however, they don't show up if I create new hardlinks with the inotify interval set really low.
The files do show up if they are not hardlinks.
My guess is that there seems to be a problem with minidlna and the way it processes the 'filesystem changes' using 'inotify'. Perhaps a hardlink isn't necessary a 'change' to notify minidlna.
My video library is rather large and continually doing rescans seems very inefficient and takes a long time. I would appreciate if someone can shed some light on this or have a workaround.
I'm running minidlna version 1.1.4
It appears it is indeed a problem with minidlna.
Depending on your use case, maybe you can create the new video file in the minidlna directory and make the one in your private movies a hardlink. The resulting filesystem will be the same, but now the first operation minidlna sees should be a full-fledged create, and therefore work.
Looks like there's no workaround to my exact problem and unfortunately my setup doesn't allow reversing the minidlna share <> hardlink directory.
The only solution I found was to rebuild minidlna RPM with IN_CREATE in inotify.c (more details here - http://sourceforge.net/p/minidlna/bugs/227/)
Hopefully Readynas makes that the default for future builds.